Risk mitigation strategies involve the security controls that address one or more risk areas. For example, preventative controls are designed and implemented to prevent a security violation from happening. Similarly, detective controls are designed and rolled out to detect a security violation; reactive and recovery controls assist in business continuity in the event of a disaster or disruptions to business processes.
This security violation can stem from either an inadvertent or malicious breach of a security policy. For example, a security policy may state that Non-Public Information (NPI) such as internal communications between board members or internal project information should not be exposed to general public. If an employee posts such kind of information in a public blog, or if he sends out such information to an external entity through e-mail, then this will constitute a security violation. Such an act by an employee may be inadvertent. However, if an employee sends out such information to an external entity for a monetary benefit, then such an act is malicious.
Regardless of the intent of the act by the employee, the violation has to be identified and categorized as an incident for suitable remedial action. Any control that captures a security policy violation is an example of a security control.
Security controls can target a specific domain as well as combinations of domains. For example, preventive-physical controls are preventative controls that address physical security requirements. Similarly, an Intrusion Detection System (IDS) is a detective control that is available for IT networks as well as physical infrastructure.
Identifying suitable security controls is based on the security assessment, which in turn is a part of the risk management process. Once a suitable security control is identified, then its integration with the systems, associated processes, and the operations they perform should be a controlled activity. Besides, the data that is used for testing and the output of testing also needs to be a controlled activity.
Information-security standards, legal-regulatory frameworks and best practice recommendations provide baseline requirements for security assessments and expected test outcomes. However, a specific security control for an assessed risk depends on the risk mitigation strategy and is sometimes specific to the type of business.
For example, a bank may require a different type of security control compared to a research organization for the similar types of IT operations. Hence, security assessment and testing draw methods that are based on a combination of baseline standard requirements and domain-specific control needs.
The following sections describe various standard security assessments and test strategies, along with the expected outcomes of such security control testing. The expected outcomes can also be termed as the performance metrics for a security control.
Generally, security control testing involves testing for the effectiveness of the control. In other words, whether the implemented control is performing as expected. A couple of examples of measurements of performance for a control would be the relevancy and adequacy of the control.
For example, to identify technical vulnerabilities in an off-the-shelf software product, relevant technical tools are required. Such tools are called scanners. However, such a tool may be inadequate for identifying vulnerabilities for logical implementation errors, which may require a different type of approach.
Vulnerability tests and assessments are performed to ascertain the presence of technical vulnerabilities or weaknesses in a system. It could be an IT system or any other automation product. Vulnerability in IT systems such as operating systems, an application software, or a network implementation can be considered as a hole or an error. Being technically an error, a vulnerability may allow a security violation to happen.
In the parlance of security, a security violation that happens due to a vulnerability is called a vulnerability compromise or vulnerability exploitation. Such exploitation may affect the confidentiality, integrity, or availability requirement of an organization's IT assets. For example, a buffer overflow vulnerability exploit may allow unauthorized access to the system or result in Denial-of-Service to legitimate users.
Tip
Vulnerability types, attacks and impacts are covered in detail in Chapter 6, Day 6 – Security Engineering - Security design, practices, models and Vulnerability mitigation.
Vulnerability tests are performed to ascertain the presence of vulnerabilities that are published either by the application vendor or by an unknown one. When an identified vulnerability is not published by the application vendor, then it is called a zero-day vulnerability. Sometimes, an exploit code may be published by security or malicious groups. Such an exploit code is called zero-day exploits.
Hence, periodical vulnerability tests have to be performed to identify known and unknown vulnerabilities. Such tests reveal the effectiveness of security controls such as patch management; and for zero-day vulnerabilities, such tests reveal the effectiveness of compensating controls. Some of the areas where vulnerability tests are performed include the following:
- Operating system software
- Application software including web applications
- Firmware
- SCADA systems
- Industrial control systems
Penetration testing is often performed to ascertain break-in possibilities to systems. In other words, penetration tests are done to ascertain the exploitation possibilities of identified or unidentified vulnerabilities that are present in the software but are yet to be identified or published.
An identified vulnerability may be exploited; in other words, the vulnerability here is tested by trying to get unauthorized access possibilities to the application or system. A penetration test simulates an attack scenario. The scenario could be from the perspective of an internal authorized user such as an employee, an external entity, or a combination of both.
The tests are performed using different attack scenarios. The scenarios are based on the level of information available to the tester or an attacker. The following section lists some of the most common test or attack scenarios.
In black box testing, the network and application details are unknown to the tester. This is to simulate an external attacker trying to compromise the network or application from external locations, without the knowledge of internal configurations and the application's infrastructure.
In white box testing, the network and application infrastructure is provided to the tester including configuration details. Hence, the test is performed to simulate the possibility of an attack by an internal user, who is an employee with in-depth knowledge about the infrastructure.
A grey box testing can be considered as a combination of black box and a white box. In this scenario, some information about the infrastructure is known. For example, vendors may need to be provided access to internal applications. However, they may access the systems from external networks or connect to the corporate networks using technologies such as VPN. This test will simulate the possibility of an attack from such a setup.
Log reviews are a part of monitoring activities. Logs reveal a trail of transactions or activities that have taken place in real-time monitoring scenarios, while the activities are going on. Generally, a log review is a part of the accountability domain wherein the activities of the authorized users are monitored.
A log is a Write Once Read Many (WORM) type of data. The protection of log data itself is an important security control. If the integrity of the log data is lost, then the log review mechanism itself will produce erroneous results. Hence, an important security control such as "segregation of duties" is enforced for such data.
The segregation of duties and other security controls are described in the earlier chapters.
These are generally used for performance monitoring, and hence, they are directly associated with the availability tenet of the information-security triad. Such kind of transaction testing is sometimes referred to as a real process or user monitoring. While log monitoring or reviewing can be used for checking all the three tenets of the information security, synthetic transaction tests focus mainly on the availability of systems and processes during different use case scenarios. Generally, a use case scenario in this type of test is stress or load testing.
Some of the tests in synthetic transactions are mentioned here.
While software or hardware is built to certain operational limits, stress tests are performed to test the robustness of the operational capabilities. For example, how much physical memory the application requires under certain test conditions, such as the number of transactions per hour, can be ascertained through stress tests.
Denial-of-Service (DoS) is a type of test used to check the availability of a service under different conditions such as multiple and simultaneous requests. Using such tests involves flooding the application or network with many requests and checking the application or network-response times. If such a test is simulated from multiple networks to a single-targeted system, then it is called a Distributed Denial-of-Service (DDoS) test.
Load tests are performed to simulate the performance of an application under load. For example, peak office hour loads versus non-business hour operations. The outcome of load tests will assist in defining or enhancing the capacity of the infrastructure or devising appropriate business-continuity plans.
This test is performed to test the application with a concurrent user activity. Generally, applications may not be accessed concurrently by all users. However, when an application is accessed concurrently by multiple users, then the request processing may get delayed. For example, the opening of a reservation window in a web application for a popular sports activity. Many users may try to book tickets at the same time, which increases the stress or load.
Any request to a network or an application may involve a round trip of data—from the user, to application, and the resultant data back to the user. A latency test is used to check the round-trip time. The more time it takes for the request to reach the application, results in more time for the response to the user and vice-versa.
Code review and testing involves testing the source code of an application for the presence of technical vulnerabilities as well as performance and logical issues. The following types of tests are applicable for code review.
A manual review of code is performed to check for any logical errors based on the application structure. Besides, such a review is conducted to check adherence to coding standards. Manual code reviews are generally done by the peer group of software developers or selected reviewers.
In dynamic code reviews, or the testing of a program, the software is executed in a simulated system or a virtual processor. In such tests, the program is fed with the required input values as well as malicious data to test the operational efficiency and security effectiveness.
Contrary to dynamic code review, in a static review a software code is analyzed without executing the program code. This process is also called static code analysis. Unlike a manual review, a static review is mostly performed using automated tools to check for security, performance, and logical issues in an application code.
When random data is fed to an application as input values (sometimes, a large amount of random data as well) to test for application performance and security, then such a test is called a fuzz test. The purpose of a fuzz test is to test for application resilience in the event of unknown or unrelated data streams.
In this type of test, the reverse of use case is tested. In other words, doing a malicious act against a system is the misuse case of a normal act. For example, if an application is designed to perform a mathematical calculation and provide an input, such as an image data, then this is a misuse case. Generally, a security attack itself is a misuse case, which deviates from the purpose for which the application was actually built, and it is done to compromise the system.
Generally, a software or an application code may not be completely taken up for code analysis due to the time-consuming process. Hence, the sample coverage of code is taken up for analysis. There may be security issues due to lesser test coverage. Similarly, all types of code reviews or other tests may not be conducted on the application. Hence, based on the security requirements, metrics have to be evaluated to identify the required tests, and the optimum level of code samples are required for testing. An analysis performed to identify such metrics is called a test coverage analysis.
User interfaces are gateways between man-machine interactions. Such interactions can be through the simple text methods of interaction—which are sometimes referred to as command-line interfaces—Graphical User Interfaces (GUI) and Application Programming Interfaces (API). Interface testing is done to ascertain the security during interactions between user to interfaces and interface to modules. For example, a user may be accessing a web application that requires a login. This is an example of a user interacting with an interface to provide an input. After the user provides the input (for example, the username/password), the application passes this to an authentication module for verification; and based on the feedback from the module, it allows the user to access the application. This is an example of an interface application to the module interaction.
An API is a method to interact with applications through request-response calls rather than through a graphical user interface. API's are generally published by the application vendor with available methods and parameters to interact with the application. An API test involves the testing of functionality, performance, and security.
A User Interface (UI) testing can include Command-Line Interface (CLI) or Graphical User Interface (GUI) testing. The focus of such tests include the operations that can be performed through user interfaces. The performances of such user interfaces and the security of data during the interactions are the focus of such tests. Besides, the usability aspects of the interface are also tested.
Physical interfaces are generally used in instruments where operating parameters can be adjusted using physical buttons, switches, rotating units, and so on. Human interaction to computing devices using touch interactions can also be grouped under physical interfaces. For example, a biometric reader is a physical input from the user. Tests such as pressure, temperature, and environmental conditions are relevant for such interfaces.
In security, the effectiveness requirements of tools take precedence over efficiency. For example, a 100% efficient antivirus software that allows 10% of critical viruses to go undetected is an ineffective application. Similarly, systems that have high false-positive and false-negative rates are ineffective as well.