Exam Questions

• Explain the phases of the secure development lifecycle. Explain two of them.

  We have five phases: Requirements, Design, Development, Testing and Deployment.

  Requirements involves defining what the product is and what the product is not. We have to document and review security objectives. We should define what is considered sensitive information, what a legitimate user can and cannot do, what a ilegitimate user could do, etc. Also we can could include regulatory requirements.

  In the Design we should perform the Threat Modeling to our product. Identify & define possible threats, designing a system architecture that mitigates as many threats as possible, considering security at a component level. Also we could design techniques to “enforce” developers to consider security during the development of the product.

  In the Development process we have to take care of enforcing the best coding practices for the language we are using. For example in C++ we should enforce STL classes instead of fragile implementations. We have to take care of proper error handling, sanitizing user imput, perform code reviews, etc.

  During the Testing phase we should perform a variety of Tests such as unit testing, static analyzers, sanitizers, fuzzing, pentestings, etc.

  Finally, at the deployment phase, we have to take care that the final product is properly secured over the years. Applying the proper patches and fixes, being properly configured at deployment, verifying that software updates are not tampered, defining a incidence response plan, etc.

• What does STRIDE stand for. Explain what it is used for and why do we do it, and which gains do we have from it.

  The STRIDE model is developed by Microsoft to classify the different types of threats and simplifies the overall security conversations.

  STRIDE stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privileges.

  Spoofing means that a user can act as another user without properly authenticating. For example being able to send messages in the name as other user.

  Tampering means being able to modify information without being detected, for example, modifying grade results.

  Information Disclosure means, as it’s name specifies, disclosing private information.

  Denial of Service means being able to take down a service/product or make it practically unusable. For example flooding the server with packets, or causing code crashes.

  Elevation of Privilege means getting privileges in the system of a superior user/role without proper authorization.

  It is used as a guidance to ease the task of classifying threats of the product, with it we can clearly view which possible scenarios we have to consider. For a certain element (for example a certain data flow) we can start clasifying it into the STRIDE matrix and see that we have to be careful for… for example… information disclosure, tampering and denial of service.

  We gain a view of the threats (with classification) we should consider for further steps in the Threat Modeling (for example Risk Analysis).

• Explain Common Criteria and which parts it surrounds.

  Common Criteria is a set of international specification and guidelines designed to evaluate informations security products and systems. It is composed of three parts: CC 01 (General Information), CC 02 (SFRs Security Functional Requirements), CC 03 (SARs Security Assurance Requirements).

  It contains a set of requirements that can be classified into families with a certain criteria and convention. These requirements can have dependencies between them and a hierarchical organization.

  For example a SAR could be AVA_VAN.1.1 where the last number specifies the concrete requirement and the rest is mere classification. That requirement can then depend to, or be hierarchical organized to, other requirements.

• Explain five OWASP Top 10 properties

  Injection: Being able to inject code, mostly, in data placeholders. A common example is SQL Injection.

  Cross Site Scripting: Bad separation of the HTML data placeholders and DOM, so we can inject HTML which is going to be interpreted by the browser.

  Improper or insuficient logging: We could not see that we have been breached with insuficient logging. I think it doesn’t need much explanation.

  Broken Authentication: Using bad authentication mechanisms such as… deterministic sessionIds for example.

  Running vulnerable software: Having widely known vulnerable software running, such as vulnerable log4j a year after the vulnerability.

• Explain five different IoT penetration tests

  Firmware and configuration corruption: Trying to find classical code vulnerabilities in the firmware that allow us, for example, to arbitrarily modify the RAM memory.

  Glitching countermeasures: Trying to perform fault attacks to bypass different countermeasures such as password checks, infinite loops in jailbroken devices, etc.

  Memory Interface: Try to modify the memory of the device, for example to change the keys or strings that are checked during some DRM checks.

  Debug Interfaces: Try to access to the debug interfaces and see if we can get a nice CLI to freely get logs from the device or modify critical configuration.

  Probing of Data Buses: Bruteforcing data buses to see if we can get something interesting from them, from corruptions to unintended functionalities.

• How does Secure Boot, Device Attestation and Sealing enhance the update process.

  When we deploy our product, as for the security product lifecycle, we will have still have to take care of it after deployment (patches, fixes, jailbreaked devices, etc.). The thing is that the enviroment is a inherently insecure, when you deploy your product, for example, a Nintendo Switch, people are going to try to jailbreak it (which let’s say you have to avoid).

  Device Attestation would help in this case, it would (remotely in this case) certify that a certain console is legitimate to access the online services. This is done thanks to the TEE (Trusted Execution Enviroment), which is a group of hardware parts/devices from the product which provide a trusted enviroment. This trusted enviroment is the one that verifies that the software has not been modified by comparing it’s hash to one that it has stored.

  Secure Boot works by verifying that the image the device is booting is legitimate, this is done by using signatures (signed bootloader stub, for example). First we start the booting process and initialize the FLASH, read from it, copy it into the RAM, verify the signature, and jump to it if and only if the signature is correct, else go to error.

  Sealing can be used to only update a certain device if it’s in a legitimate state. It will seal/unseal values depending on a certain state (PCR value, basically a hash chain), it binds the keys and the consecutive actions to a specific platform state.

• Explain Threat Modeling and Risk Analysis/Assessment

  Threat modeling works to identify, communicate and understand threats and mitigations within the context of protecting something of value. A threat model is a structured representation of all the information that affects the security of an application. Basically it can be seen as an security overview.

  We use it to be able to understand the security requirements, discover and communicate new threats so that everyone in the team is in sync with the security aspects, serves as input for testing, requirements validation, etc.

  Threat Modelling answers what assets need to be protected, what are the threats to these assets, how important or likely is each threat and how we can mitigate the threats.

  Risk Management is a methodology that measures the identified risks (threats) by \(impact \cdot likelihood\). The impact, as it name says, measures how wrong a successfull attack would affect the product (how many users it would affect, availability compromised?, data breach? etc), while the likelihood means how likely the attack would be (needs physical access? skill of the attacker? multiple attackers? insider needed?). The total multiplication of these two values is considered as risk.

  Also, for each risk value (likelihood/impact) combination we should define a matrix that differentiates each case as (acceptable, conditionally acceptable and unacceptable). Depending on our matrix/table definition we should act for each defined threat/risk.

• What are the phases of a Web Application pen-test? Describe each phase.

  We have Contract, Discovery, Attack and Report.

  During the Contract phase we have to perform some legalities such as (proably) signning an NDA (Non Disclosure Agreement) to legally state that you won’t share information from the pentest without permission. Also you should state what you will be doing (for example, just testing OWASP 10), under which timeframes, what is not going to be tested, the scope (domains) of the pentest, etc. The most important document you have to sign is the permissionm to attack the infrastructure (with the previous conditions). It’s very important that you follow this contract and under any circunstances don’t do anything that it’s not stated in it.

  During the discovery phase we have to learn which services the application is running, under which ports, which software it is running, under which version, etc. Any information that we see as valuable for our pentest. The we’ll use the information to tailor our attack to the infrastructure.

  In the Attack you have to, well, attack the infrastructure. By using the information discovered previously and by following the contract guidelines, you have to try to bypass and breach any security measure the application has.

  Report: At the end of the pentest you have to write a report with your findings, including sections such as executive summary, technical reports, etc. You should include what you have tested, what you have not tested, the timeframe you had, and state that showing the absence of bugs is not possible under a pentest.

• What are the phases of a IoT pen-test? Describe each phase.

  We have Identification, OSINT, Remove Casing, Component Identification, attack.

  During the Identification we should be able to properly identify the product we are pentesting. This can be seen as an easy task but can be challenging, we have to be very precise with the versioning of the product.

  OSINT. In this phase we have to gather all the information publicly available about the product. From device manuals to papers, specifications, etc.

  Remove Casing. This process can be either trivial or very hard. You have to remove the casing of the product, which in some cases such as IoT devices can be easy, but if we are pentesting a processor can be hard, as we have to decap the processor.

  Component Identification. Now with clear vision to the electronic parts of the device we have to identify each electronic component, with specific serial numbers if possible. We can go back to the OSINT phase and gather again more public information about each component.

  Finally we have tha attack, where we use everything learnt to try to exploit the device. There are a few attacks such as memory attacks, security measures glitching, data bus attacks, debug interface access, firmware or configuration corruption.

• Explain how requirements are managed

  Requirements model how our system will behave, thus to keep the system secure, security requirements are needed. Requirements can be managed, for example, with a Security Target document (Common Criteria), and we can define the Security Functional Requirements and Security Assurance Requirements.

  We can also use Threat Model and Risk Analyis to extract how certain requirements should be handled, for example, prioritizing those who have more risk or are more likely to happen.

• What is threat modelling? Why do you do threat modelling? What do you have to consider? Which models are you using?

  The Threat Model is a structured view of all the information that relates to the security of our product. It has as the main goal to identify, comunicate and understand possible threats of a product to a entire team of developers/architects. The Threat Modeling is the methodological process to obtain the Threat Model, which should be done in the Design phase of the Secure Product Lifecycle and taken into account during the product lifecycle process.

  We do threat modeling to identify the threats we have to protect from, which imply the most risk, keep in sync the team of the developers of the security implications of the aspects of the product, use them as input for the testing phase, etc.

  We have a few models such as Microsoft STRIDE, Attack Trees, OWASP IoT, LINDDUN.

• What are the types of input generation in fuzzying?

  Random, Mutation Based and Generational.

  Random means random, the input is generated randomly and sent to the program. This type of input generation is rather easy but it will fail a lot if the program has some input format specification (starting with \texttt{$} the commands, for example).

  Mutation Based takes a input example and starts mutating the input in some pseudo-random ways to find malformations of a expected input that make the program misbehave. An example is \texttt{radamsa}.

  Generational input generation is the most complex one, requires complete knowledge of the protocol/input to analyze to specially craft malformed input for that protocol. For example you can buy specific generational input fuzzers for the USB protocol.

• What is common criteria? What is ST and PP? How are they related?

  Common Criteria is a set of international guidelines and specifications designed to evaluate the information security of products and system. It’s composed by three parts: CC 01: Introduction and General Model, CC 02: SFRs (Security Functional Requirements) and CC 03: SARs (Security Assurance Requirements).

  The ST is the main document regarding the security of a product. It states the security requirements a certain product has. It is written by the vendor of it’s product, it usually contains the SFRs and SARs. It states how the system should behave and how it should be tested. We can only issue a certificate for something that it’s stated in the ST.

  The PP is something more general than the ST. It’s written by some standard company and it’s not specific for a certain TOE, but for a class of TOEs for example: firewalls, smartcards, etc. It’s a similar thing in the sense of that includes how the “generic” TOE should behave and how it should be tested, but for a whole class of TOEs. If we have a product that adheres to a public PP, we can say that our product is PP compatible/certified etc.

• What are the different types of penetration testing?

  Whitebox, Blackbox and Greybox

  In whitebox penetration testing we have knowledge and access to the entire system. For example if we have to test AES, we would know how AES works (obviously in this case) and we could modify AES internally (round level, for example). In a web scenario we could have access to internal information such as source code, api endpoints, admin accounts, etc.

  In blackbox testing, basically we are at user level. We don’t have access to anything that could be considered insider information, we are practically treated as an external user. The TOE we are going to test for us is practically a blackbox, and we have to guess how it works internally to start pentesting it.

  Greybox testing is a mix between the last two. I doesn’t have a proper definition but you are given more information/facilities than a external attacker/user but not complete access to the system.

• OWASP MASVS & MSTG?

  OWASP (Open Web Application Security Project) is a nonprofit organization that tries to empower the security of web applications. MASVS and MSTG are projects related from the mobile security field that OWASP has.

  MASVS (Mobile Application Security Verification Standard) is a list of things/requirements that you should consider regarding the security of your application. Some of them include resistance to reverse engineering, security of transmission channels, prover usage of enviroment elements, secure architecture/design, code quality. It has eight chapters numbered from V1 to V8.

  MSTG (Mobile Security Testing Guidelines) is a document that defines how the previous requirements should be tested. It also contains three different verification levels which can be combined: L1 (Basic Security), L2 (Improved Security), LR (Resiliency against tampering and reverse engineering).

• Differences of penetration testing of a IoT device and a high security products?

  While pentesting an IoT device we can have much less samples available to try our attack with, so we have to be conservative about our attacks. Also the time of testing is probably going to be higher, as for example, waiting the device to reboot after a failed exploit/fault can take longer. Another consideration is that the system can be much more complex than a small security product, which can be good and bad at the same time, bad because we have much more things to understand, but better because we gain a lot more surface to attack.

  In high security products we usually have much more samples available to test (for example, smartcards). The time to test is usually less (smartcards are fast, or don’t need reboots, etc). Also they are much more simpler to understand, so we have less things to look for.

• Why long term security?

  We should consider long term security as some devices are going to be out there for arround 20 years. Consider a router device, we don’t know how much is going to be in use, most of the time it gets forgotten and it stays there for long periods of time. Think the same with smart TVs, smart locks, etc.

  So we should consider the possibility that, if we release a certain product now, it will be out there for 20 years or more. Even if now the device is completely secure, is resilient to quantum computers (crypto)?

  So we have to think in the long term (for some devices) and apply some mechanism that protect that device in the long future. For example by implementing early mitigations (quantum resistant crypto), or methods to update the current technology to a resistant version in a future, when it’s needed.

• What makes a good Build Enviroment? What do you have to consider?

  A good build enviroment should enforce security and good coding practices during the entire development process, for example. We should enforce static code analysis at each commit, also enforce the unit tests, sanitizers, etc. The build enviroment should also have a accept process for pull requests where certain users have to sign/verify pull requests before merging them into the codebase (as it happens in the linux kernel with the reviewed-by attribute).

  Also we have to be strict with them and don’t allow a naive developer to bypass the checks (force pushing, disabling unit testings even if temporaly, etc.).

• Explain Threat, Risk and Vulnerability

  Threat: a potential security violation in our product, coming from a weakness or a vulnerability

  Risk: metric defined as consecuences of a threat multiplied by it’s likelihood

  Vulnerability: weakness on the product for which a exploit does exist

• Explain Secure Architecture

  Security architecture is a unified security design that addresses the necessities and potential risks involved in a certain scenario or enviroment. It also specifies when and where to apply security controls. It should be simple, understandable and implementable. Security Architecture domain contains the concepts, principles, structures and standards used to design, implement, monitor and secure operating systems till .

  An architecture is at the highest level when it comes to the overall process of system development.

• Explain Security by Design

  Security by Design means integrate the security point of view into every part of the product development cycle. This set of rules are more or less general for each product and are based con common battle-tested knowledge. For example one statement is that each process should run with the least privilege possible to acomplish it’s task (Least Privilege Principle). Also we should take into consideration closing unused ports.

  Basically we have to design our product with the fact in mind that it will be attacked, integrate security controlls from the beggining and make security tests a critical part of the development proces.

  Take malicious practises for granted, if anything bad could happen, it will happen, so apply general concepts and common logic to try to mitigate these risks.

• Explain Security Evaluation and Certification. What do you need to consider by the Security Claim?

  The process of the certification starts by the TOE/product to be tested. In the certification step we have four different phases: security claim, paper work, functional, vulnerability assessment. In the security claim the certificator company states the requirements needed, in the paper work there’s all the legal work required to pass the certification (regulations, etc), then in the functional security the security mechanisms are tested for it’s correctness, finally on the vulnerability assessment we check if the security measures can be bypassed.

  After the evaluation, a report is obtained and if it’s passed, it can be sent to the certification authority to get our certificate.

  In the security claim we have to consider that, the more complex our functionality is, the more work we are going to need on the certification, and the higher the assurance level is, the higher the effort is too. So you should adjust these two variables to something considerable for your project.

• Explain Functional Security Testing vs Robustness Testing

  Functional security represents the technical implementation and it’s lack/presence of weaknessess in the implementation. For example, if a pinlock is properly implemented (no backdoors, no bruteforce, no bypass).

  Robustness security represents the logical security of our product/security subset of the product. For example if the pinlock is properly implemented & secured, but the window right to it it’s not, then we cannot benefit from any security of the pinlock, even if it is properly implemented.

• Explain Different testing methods for mobile apps

  The same answer as for web application testing methods, just different examples. Whitebox, blackbox, greybox.

• Explain the Root of Trust, Secure Boot, Trusted Execution Enviroment

  Root of Trust is the lowest level of the security stack of our device. The Root of Trust serves as the lowest point in the hardware/software stack that we actually trust, it performs critical tasks such as storing cryptographic keys that will be used and enables the secure boot process.

  Secure Boot is a security mechanisms were the booted image is verified to be legitimate before jumping into it, so any modification even at the lowest level of the software stack would be rejected (as it’s not signed).

  The Trusted Execution Enviroment is a conglomerate of security related hardware/software components that are isolated from the normal computing enviroment. It can execute TA (Trusted Applications) that will be safe even in a unsecure and compromised operating system, bootloader, etc. An example of this is ARM SecureZone or Intel SGX.

• User/Security guidance

  The User/Security guidance is a document provided to the end user of the product stating the steps to perform an secure and safe deployment of our product, in such a manner that keeps the security claims that we stated and verified. It’s defined as a list of tasks that directly affect the security of our product, the user should be able to follow this taks and end up with a secure product at the same level as we stated.

  Also we can include a guide of how to securely operate the product, for example we could mention how we should check for updates and how to apply them, etc.

• After market tasks

  After deploying a product, there is a few tasks we have to keep performing and taking care of. Patching, Market Surveillance and Secure Decomissioning.

  Patching/Manteinance is quite straightforward, just keep updating the product as new vulnerabilities emerge.

  Market Surveilance is taking care of EU/vendor checks for device correctness/safety. They draw random samples and check they follow the stated certification, EU rules, etc.

  Secure Decomissioning. After a device is no longer used, wipe all user data, lock out fired users, wipe configurations, wipe secrets, etc.