Cloud Development Basics

According to the Cloud Security Alliance (CSA) and SAFECode, the development of collective responsibility is essential but can be challenging when building a safety-conscious application development program. This effort can be broken down into three parts.

• Security by design: This implies that security is part of every step in the process, not simply an activity that occurs after an application is built or a reactive response to an identified flaw. Security requirements should be documented along with all other system requirements at the beginning of development, and adequate attention must be paid to ensuring that the system meets those requirements. Various models exist to help design these processes, such as the Building Security In Maturity Model (BSIMM).
• Shared security responsibility: The idea is that security is the responsibility of everyone from the most junior member of the team to senior management. No one should say that security is not their responsibility—instead, it is recognized that security is the result of individual responsibility and trust. The shared responsibility model in cloud computing is a similar concept, where both the provider and customer have explicitly defined responsibilities and must work effectively together.
• Security as a business objective: Organizations that have a compliance-driven approach to security can sometimes see it as nothing more than a roadblock. However, a security incident can cause significant or even fatal disruption to an organization's operations. Security controls help to prevent or avoid these risks, so understanding security risks and ensuring that they are mitigated should be a key business objective, similar to customer satisfaction or revenue.

Each of these basic concepts requires a clear understanding of organizational culture, security vulnerabilities, and organizational vision and goals. Without an organization-wide understanding of security and proper resources, software development and application security in the cloud are unlikely to be successful.

Common Pitfalls

One of the most common pitfalls related to cloud security is a lack of understanding the responsibility for securing the cloud. Even though major cloud service providers (CSPs) publish their shared security model, it is common to find cloud consumers who believe that all aspects of IT are outsourced to the cloud provider—including security. Ensuring that organizational leaders are aware of what responsibility the organization retains is a crucial step in avoiding a dangerous mentality of ignoring security risks.

Once leaders are aware of the need for proper security, another pitfall awaits. Inadequate support from senior management for cloud application security initiatives will lead to inadequate resources and wasted effort. Efforts to instill a security culture are unlikely to be successful unless senior leadership supports these efforts—through their approval and adherence to security policy as well as funding and staffing security initiatives that are part of organizational goals.

The next pitfall is failing to understand organizational culture. Even companies in the same industry have very different cultures. Building and sustaining a security culture requires careful planning that recognizes an organization's existing culture and employs sound change management tactics to introduce security into the culture. In addition, program-level efforts must be reviewed regularly to ensure that they remain aligned with business objectives and cultural realities. For example, a culture that places high value on speed and efficiency is unlikely to embrace security processes, like approval of new cloud services, that add significant delays.

Another resource-related pitfall is staffing. The size of an organization may limit the number of security experts due to competing hiring needs or even resources available for security practitioner salaries. These experts may then serve as resources to multiple development processes rather than as a member on one team. If the organization is large, development teams may use security experts as resources or may include security experts as team members. In either situation, it can be challenging to ensure that the development of security-aware applications will be consistent across the organization.

Organizations that do not implement a framework for secure software development will also cause difficulties. A mature organization will have a well-defined process that integrates security as part of each step. The lack of a framework or process leads to ad hoc security and does not support a security-aware organization.

Finally, in times of budget constraints, the training budget is often a first target for budget cuts. It is easy to cut training without immediate impact; however, a security-conscious organization should find ways to continue security awareness training and secure development practices. Switching from instructor-led training (ILT) to computer-based training (CBT) is one such strategy. CBT may be somewhat less effective, but it still provides useful training at a reduced cost and helps achieve a better cost-benefit outcome than eliminating training entirely.

Additional security training options include subscriptions to online security courses, as well as online asynchronous and synchronous training. Each of these options eliminates travel expenses and is typically lower cost than live, in-person training. One other option is to bring the trainer to the work location. If a large number of people need the same training, bringing the trainer to you rather than sending the people to training can be cost-effective. These options can keep training active while trimming the budget.

Common Cloud Vulnerabilities

Common cloud vulnerabilities include data breaches, data integrity, insecure application programming interfaces (APIs), and denial-of-service (DoS) attacks. The broadly network-accessible nature of the cloud and need to exchange data between networked systems introduces some specific vulnerabilities into cloud computing. Any time an application is accessed or transmits data over the Internet, it is doing this in a hostile environment.

There are several organizations that provide information on security threats, including the Cloud Security Alliance (CSA), the SANS Institute, and the Open Web Application Security Project (OWASP). They publish research on top threats in cloud computing and related technologies, and offer routinely updated content on general, cloud, and application security topics. The following sections contain examples of the risks from each organization and further reference materials.

NIST Secure Software Development Framework

Similar to the popular NIST Cybersecurity Framework (CSF), the NIST Secure Software Development Framework (SSDF) defines and describes secure software development practices (csrc.nist.gov/publications/detail/sp/800-218/final). This framework is useful for developing secure traditional IT systems, as well as Industrial Control Systems (ICS), IoT systems, and cyber-physical systems (CPS).

The SSDF can be adapted to existing SDLCs, supports the use of modern software development techniques such as agile, and leverages guidelines and standards from other organizations.

The SSDF is organized into these four groups:

• Prepare the organization: This includes people, processes, and technology.
• Protect the software: Protect it from tampering and unauthorized access.
• Produce well-secured software: This means software with minimal vulnerabilities.
• Respond to vulnerabilities: This includes preventing them in future releases.

OWASP Software Assurance Maturity Model

The OWASP SAMM can be used to assess the current state of secure development using an existing SDLC and to identify improvements that increase the maturity of these practices. It is ideal for organizations with well-established SDLC methodologies and processes and is useful for defining the current state as well as key activities to move to a desired state within the existing SDLC practices.

The SAMM (owaspsamm.org) consists of domains subdivided into security practices, which are used to measure software security maturity and develop actionable plans to improve the SSDLC capability. The domains and practices include the following:

• Governance: Strategy and Metrics, Policy and Compliance, Education and Guidance
• Design: Threat Assessment, Security Requirements, Security Architecture
• Implementation: Secure Build, Secure Deployment, Defect Management
• Verification: Architecture Assessment, Requirements-driven Testing, Security Testing
• Operations: Incident Management, Environment Management, Operational Management

SAMM provides assessment tools and guidance to improve an organization's security posture and supports the development of secure software and systems.

Business Requirements

Mature software development shops utilize an SDLC because it saves money and supports repeatable, quality software development. Studies have been conducted that show that the later in the development phase issues are found, the more expensive it is to fix those issues. Adding security to the SDLC benefits secure software development, because security issues that are discovered after a system is developed can be costly or even impossible to fix. Minimizing the number of flaws that make it into a final system is a more cost-effective approach than trying to mitigate security risks after the system goes live.

While the SSDLC adds some up-front cost to the development of new software applications and the modification of existing applications, identifying security vulnerabilities early will lower overall development costs. The expected return is software solutions that are more secure against attack, reducing the exposure of sensitive business and customer data. Bolting on security after the coding or deployment phases simply increases the cost of that security while limiting its effectiveness.

However, an SSDLC is fully successful only if the integration of security into an organization's existing SDLC is required for all development efforts. Only when secure development is a requirement of a business will security by design occur consistently.

Business requirements capture what the organization needs its information systems to do. Functional requirements can include parameters like supporting up to 1,000 concurrent users logged in, which in turn support business requirements like all users being able to access a system during the workday to perform their assigned duties. In addition to these functional requirements, the organization must also consider security, privacy, and compliance objectives that must be met.

For example, a system that processes healthcare data is likely to have legal and regulatory requirements for protecting data. This will drive system requirements such as encryption of data at rest and in transit, role-based access control to ensure that only authorized users can view information, and data retention schedules and supporting infrastructure such as cloud backups. Requirements are an essential part of all SDLCs, and ensuring that these requirements include security objectives is a key trait of a more mature SSDLC.

Phases and Methodologies

There are many models for SDLCs, from linear and sequential approaches, such as waterfall, to interactive and incremental approaches, such as spiral, agile, and most recently DevOps, which increase the speed and frequency of deployment.

There are several primary stages to any SDLC. If these stages incorporate explicit security-focused practices, like documenting security requirements and documenting acceptance criteria for security testing, the organization has created an SDLC that considers security from the very beginning, creating an SSDLC. The generally accepted SDLC stages are as follows:

• Requirements: This phase includes all parts of the planning and can include feasibility studies, as well as gathering business, functional, and security requirements.
• Design: The design step starts as a high-level design and gets increasingly detailed as this stage progresses. The design must address all requirements, including security requirements, that were identified in the prior phase. Design can also include the design of test cases that will be used to determine if the system is fit for use. Test cases should be tied to specific requirements identified in the requirements stage and should be designed to simulate both expected and unexpected use of the system to identify any errors, flaws, or functions that do not meet the requirements.
• Development: The coding phase is the creation of the software components as well as the integration or build of the entire solution. This can involve custom development of all elements of the system, as well as the use of commercial off-the-shelf (COTS) software and cloud services. During development, unit testing is generally performed as various parts of the system are completed or integrated.
• Testing: This phase is the initial testing of the solution built, as well as more focused testing that occurs to validate the solution before the final phase. This should include testing of all use cases and traceability of how test outcomes map back to requirements. For example, if the system must provide protection for data in transit, then all interfaces where data leaves the system over a network should be tested to verify that encryption is in place and operational.
• Deployment: Deployment is the work associated with the initial release of the software. Part of the effort in this stage is to ensure that default configurations conform to security requirements and best practices, including configuration of application programming interfaces (APIs) and any identity and access management (IAM). These steps reduce the risk of credential compromise and also protect the processes for account creation, maintenance, and deletion. Deployment is also where hardening measures are taken, to ensure that system components are installed in a secure manner. For example, if a cloud storage service is to be used in the system, it should be configured with only the minimum necessary access permissions. It is a good practice to consider each service that is approved for use by a business and create a standard configuration guide for each of those services to ensure a secure configuration for each service that adheres to company standards.
• O&M: This is usually the longest phase in the lifecycle, as it encompasses everything that happens after the release of a software solution. This stage includes all operational, monitoring, and maintenance needs of the solution, including ongoing security activities like logging, access reviews, and incident response.

Each phase of the SDLC can be divided into ever finer phases with associated security activities to make an SSDLC. The steps presented here capture the general flow of most SDLC methodologies. Organizations may choose a predefined methodology, such as the NIST SSDF, or choose to build one customized to their specific operations. At each step, security tasks and practices are an important part of the overall solution. Following these steps leads to a consistent and repeatable process for designing and delivering secure software.

Different SDLC methodologies exist, from traditional models like the waterfall to more modern approaches like Agile and DevOps. The choice of a methodology, similar to the choice of an SSDLC framework, may be dictated by an organization's existing development practices as well as the types of products or services the organization delivers.

Cloud-Specific Risks

Cloud-specific vulnerabilities identified by the CSA Egregious 11 can lead to violations of one of more of the CIA triad requirements of confidentiality, integrity, and availability. Breaches, compromises, or unauthorized exposure of data can lead to legal and regulatory violations. For example, a breach of payment card data can lead to an organization losing its ability to process payment card transactions, which is likely to have a catastrophic effect on revenue. At the least, a well-publicized data breach can lead to a loss of reputation, loss of new business, and market share. Loss of data integrity and availability can have similar consequences.

Risks beyond those discussed by the CSA will exist for specific companies at different levels of security maturity, in various industries, and in different geographic locations. Security practitioners should work to identify the organization-specific requirements that they face, such as specific geographic privacy legislation or industry-specific requirements for the type of data they are processing. Cloud-specific challenges that can cause issues include the easy cross-border transfer of data in cloud environments, as well as the issues associated with the organization losing direct control over their infrastructure when it is provided by a CSP.

Any organization using computing should analyze cloud-specific risks that affect the organization's data and information systems. As discussed in the previous section, the choice of a framework for the SSDLC will be guided by other standards already in use. For a cloud-native organization, the CSA Egregious 11 can be useful when addressing cloud-specific risks in software development. In an organization with a mix of cloud and legacy, on-premises infrastructure, frameworks like the OWASP Top 10 may be more appropriate as they contain less cloud-specific guidance.

While there are many risks present in cloud computing, the CSA Egregious 11 (cloudsecurityalliance.org) is a good summary of cloud-specific risks. The CSA Top Threats working group has published the Egregious 11 as well as a deep dive that provides additional examples, clarifications, and mitigation options for each of the identified threats. A high-level explanation of each of the 11 is presented here, along with specific examples of flaws or vulnerabilities in cloud applications that highlight these vulnerabilities.

• Data breaches: Confidential and restricted data should, as the name implies, remain confidential. This can include sensitive personal information or intellectual property, and data breaches are primarily an attack against confidentiality. They can lead to fines, legal or contractual liabilities, and a loss of customer trust. During requirements gathering, the types of data to be handled must be documented, as well as associated protection mechanisms like access controls or encryption. These controls should be thoroughly tested to ensure that they achieve an appropriate level of risk mitigation based on the sensitivity and value of the data.
• Misconfiguration and inadequate change control: Software can offer the most secure configuration options, but if it is not properly set up, then the resulting system will have security issues. Misconfigurations at deployment or inadequate procedures for controlling changes can result in systems with security vulnerabilities even if security was designed in—a secure facility where the front door is left unlocked can be less secure than a facility where basic security hygiene is observed. At deployment the organization must ensure that all security-relevant settings are properly configured. As part of change control, the organization should analyze any proposed changes for security impacts, and verify that deployed changes do not result in a degradation of system security.
• Lack of cloud security architecture and strategy: As organizations migrate to the cloud, it is easy to overlook security. After all, cloud computing has significant advantages for an organization's finances, but it is dangerous to overlook the security implications of migrating to the cloud. Ironically, the initial cost savings the cloud offers can be quickly offset by sprawling cloud deployments. A coherent security architecture for cloud computing should comprise well-documented shared-responsibility items, as well as organization-specifics for proper cloud usage given the organization's unique business processes and data needs. ISO 27001 clearly identifies the need for coherent strategy and executive support for a security program, and this concept applies equally to cloud computing.
• Insufficient identity, credential, access, and key management: Cloud computing offers many benefits over legacy computing environments, but it can also introduce additional complexity. In a traditional on-premises environment all systems may be able to talk directly to a single identity and access management (IDAM) service on the same network, but cloud resources that exist in different CSP environments lack this capability. This can easily lead to problems like user exhaustion creating and remembering passwords, and issues related to logging and monitoring if user access logs are spread across disparate systems. A key part of a cloud security strategy must be a well-architected IDAM strategy, and the importance of encryption in cloud environments necessitates a robust approach to key and secret management.
• Account hijacking: As the name implies, this risk relates to attackers gaining access to and abusing valid user credentials to gain access. Administrative and service accounts are a high-value target as they often have broad access within an environment, and the broad network accessibility of cloud services makes these attacks easier since a stolen set of credentials can be used anywhere an attacker has Internet access. Safeguards against account hijacking are similar to the practices in privileged access management (PAM), including practices like separate administrative credentials, increased use of MFA, more robust auditing, and awareness and training to help users of these accounts avoid common risks like phishing.
• Insider threat: Insider threats can come from malicious sources, like disgruntled employees, or nonmalicious sources, like careless or overworked employees who make mistakes. Insiders do not need to gain access to an environment to cause issues and may have a higher level of access than an outsider could gain, which makes these risks high impact. Ensuring adequate training and security awareness to avoid careless mistakes is essential, and additional practices like robust auditing or break-the-glass procedures for gaining access to emergency administrative privileges can help safeguard against these types of risks.
• Insecure interfaces and APIs: Cloud computing offers services in novel ways, such as accessing systems using APIs and managing virtual infrastructure using a web-based console. Improperly securing these interfaces can lead to new vulnerabilities that were not present in legacy computing environments; organizations moving to the cloud may be unaware of these risks. Since these interfaces are accessible via the Internet, additional security measures may be required if they expose sensitive systems or data. Controls against insecure interfaces include the use of strong authentication for any access, such as MFA for console users or key-based authentication for API access. An SSDLC for cloud applications must include interface testing, due to the heavy reliance on APIs in cloud computing, and specific attention should be paid to testing the security of these interfaces.
• Weak control plane: The control plane refers to the elements of a cloud system that enable cloud environment configuration and management. A weak control plane is one in which the system architect or controller has limited oversight or control capabilities, which can lead to a loss of data confidentiality, system availability, or data integrity. CSPs typically provide the control plane in the form of a web app or command-line interface. Additionally, most CSPs offer security reference architectures that specify how to properly secure the cloud environment and control plane, including practices such as adequately segregating environments for production data from environments used for development or testing.
• Metastructure and applistructure failures: This risk can be difficult to comprehend, since metastructure and applistructure refer to entirely virtualized concepts in the cloud with few examples in the legacy, on-premises world. At a high level, these concepts refer to the operational capabilities that CSPs make available, such as standard computing images and APIs for accessing various cloud services. If the CSP has inadequately secured these interfaces, any resulting solutions built on top of those services will inherit these weaknesses. Cloud customers have little capability to directly address these risks, since the CSP bears the responsibility. Instead, cloud security practitioners should look for evidence that a CSP has implemented their own SSDLC and conducted testing against their service offerings to validate the security of the cloud service. This might include API security testing, penetration testing, or verification of cloud services against third-party standards.
• Limited cloud usage visibility: Using a CSP can help an organization realize cost savings, but the use of a service provider also removes the organization's visibility into how its systems are operated. CSA breaks this threat down into two sub items: unsanctioned app use and sanctioned app misuse. Unsanctioned use refers to the practice of shadow IT, where organizational users acquire and use cloud services without official approval, leading to loss of data control and visibility. Sanctioned app misuse refers to the use of approved services for nonapproved purposes, such as storing sensitive data in a cloud service that is not approved for data of that classification. Security training and governance can be effective safeguards, and some security tools like data loss prevention (DLP) and data flow tools can help augment visibility into cloud service usage.
• Abuse and nefarious use of cloud services: Cloud computing makes massive computing power much more affordable. While this is an advantage for organizations looking to save money, it is also advantageous to attackers, who can now access massive computing power at a cost-effective rate. This computing power can be put to nefarious uses, such as launching distributed denial-of-service (DDoS) attacks, conducting phishing campaigns, or hosting malicious content. CSPs are largely responsible for implementing controls that mitigate these risks. All organizations should be evaluating changes that cloud computing has brought to the threat landscape. For example, DDoS attacks that were financially impossible a few years ago might be possible now with rented cloud computing capacity. This can increase the likelihood of a DDoS attack, which should in turn drive additional investment in risk mitigations.

Threat Modeling

Threat modeling allows security practitioners to identify potential threats and security vulnerabilities and is often used as an input to risk management. When applied to software development, threat modeling can help with prioritizing secure development activities. For example, an Internet-facing application will face different threats than one only used internally by an organization—any attacker in the world can reach the first one, while a much smaller number of users will have access to the second.

There are numerous frameworks for threat modeling, but they all share similar characteristics. As with many aspects of application security, OWASP has a reference page that details how these models can be applied to achieve an SSDLC: owasp.org/www-community/Threat_Modeling. All threat models allow security teams to identify potential threats and break them down into different elements, which can be used to assess the threat and design mitigations.

The process of conducting threat modeling will vary based on the framework chosen. No single model is appropriate for all organizations, as the business processes, geographic locations, and risks faced will vary based on the organization's unique circumstances. When designing a threat modeling program, it is important to choose a model that aligns to the organization's specific operations. For example, the PASTA model can be applied to organizations with blended computer- and human-based information processing, while STRIDE includes elements that are more applicable to electronic information systems. Once a model has been chosen, a security practitioner should seek out adequate training, reference material, or consulting applicable to the specific model to ensure that it is properly applied.

Avoid Common Vulnerabilities during Development

Common cloud vulnerabilities are well-known and documented in lists like the OWASP Top 10 and CSA Egregious 11. Avoiding them can be achieved in several ways. Like all risk mitigations, a layered approach combining multiple types of controls is a best practice. These controls include the following:

• Training and awareness: Training for developers is critical, because they make decisions about how to design and implement system components. If a developer is unaware of flaws like injection attacks and codes an application with one of these flaws, the system is at risk. Training and awareness targeted at these audiences is a useful countermeasure, such as OWASP Top 10 awareness and training on how to avoid these vulnerabilities in the specific coding languages used by the organization.
• Documented process: The SSDLC should be well documented and communicated to all members of the team responsible for designing, developing, and operating a system. This is similar to security policies, which must be well understood by users if they are to be followed.
• Test-driven development: Ensuring that security requirements are met can be challenging, but focusing on meeting acceptance criteria can be one way of simplifying the task. Having well-defined test cases for security requirements can help avoid vulnerabilities such as Top 10 flaws, since developers know that testing will be conducted against those criteria.

Secure Coding

The practice of designing systems and software to avoid security risks is a proactive risk mitigation step. As in many areas of security, there are standards and organizations designed to mature these practices, such as OWASP. Since these security practices are designed by external parties, they may not be a guaranteed fit for an individual organization, but by tailoring the practices identified in one of these standards, any organization can build a secure coding capability.

Software Configuration Management and Versioning

The purpose of software configuration management (SCM) and versioning is to manage software assets, and it focuses on maintaining the integrity of critical information system components. A loss of integrity could result in unexpected or unwanted system behavior, such as an access control module failing to adequately restrict access, which could in turn lead to a loss of data confidentiality if unauthorized users gain access to sensitive data. This practice can be challenging as software is almost always developed by teams, whose members may be geographically dispersed and work asynchronously. Multiple people may be making changes to both the config and source code files. Properly managing all of this is essential to ensure that changes are current and accurate, and the final software product contains the correct versions of all source code.

Properly managed SCM can make rolling back changes possible, so if a loss of integrity does occur, it is possible to restore the system to a known good state. Versioning can also maintain copies of the configuration and software for deployment to different machines and operating system versions, which can be useful in a disaster scenario if manual recovery is needed. Version control can also be a critical element of a compliance program, as system configurations may be unique to meet various customer, geographic, or regulatory framework requirements.

A key role of SCM occurs at deployment and during O&M release management for system updates and patches. Without formal SCM tools and processes, it is possible for incorrect software versions to be released. This can be a costly error, exposing the organization to reputational, operational, regulatory, and contractual issues.

SCM also allows for configuration audits and reviews by providing the artifacts necessary to verify whether processes are being followed. Compliance with requirements may be related to an organization's policies, regulatory requirements, or contractual obligations. The evidence generated during SCM processes, such as version checking before deployment and well-documented rollback plans, supports the ability to quickly and accurately perform audits.

SCM and versioning should be common practices in all software development environments and can be implemented along with other configuration management processes and tools like a configuration management database (CMDB). It may be possible to federate the CMDB with both on-premises and cloud-based solutions, which enables tracking of SCM regardless of where the software is deployed. Organizations that are cloud-native may not require a federated CMDB if their entire infrastructure is in the cloud.

Similar to SSDLC choices, each organization will need to decide how to implement configuration management. It is as important to perform configuration management on premise as it is for software development in the cloud, and each organization's mix of on-premises and cloud infrastructure will be different. In general, the SCM program must support versioning, provide assurance that the correct versions of various software modules are being deployed during a release, and allow for auditing of the entire lifecycle to support the implementation of an SSDLC.

Functional and Non-functional Testing

Functional testing is used to test that the functional specifications of the system, linked to system requirements, are met. The execution of a robust set of test cases, linked to functional requirements, will create a level of confidence that the software operates as intended.

There are many ways to test software, but there are some well-defined categories of testing that are defined by the goal of the tests performed. The primary categories of testing that lead up to functional testing are unit testing, integration testing, and usability testing.

• Unit testing: This is testing by a developer on a single unit, often a function or module, that is developed as part of a larger system. All paths through the function module should be tested.
• Integration testing: As modules are combined, integration testing ensures that the modules work together. These modules may be developed by the organization or may be acquired software such as operating systems that integrate to provide a full application. As additional modules are added, we get ever closer to functional testing.
• Usability testing: This testing uses customers in a production-like environment to get feedback on the interaction between the user and the system.

As the modules are tested and then are integrated (and tested) and the user's feedback is obtained and incorporated into the system, we get to the point where we are ready to perform functional testing on the entire system. When conducting functional testing, there are important considerations that include the following:

• Testing must be realistic: Many development shops have Dev, Test, Stage, and Prod environments. These environments are called lanes in some organizations. The Dev, or development, environment can be set up to suit the developers' needs. However, for the greatest assurance, the Test and Stage environments should be set up as closely as possible to the Prod environment. In many cases, the Test and Stage environments will have live data or older copies of live data to ensure that functional requirements are met. Once development is complete, the application moves to the Test environment for testing. Upon successful testing, the application will move to the Stage environment for configuration management and potentially additional testing. Once the next release cycle occurs, the software in the Stage environment moves into production. Any environment with live data (current or older) must be protected as well as the Prod environment to prevent data loss.
• Acceptance: Testing must be sufficient to guarantee that the application service meets the requirements of the customer and the organization (sometimes they are the same). This means that testing must be designed to exercise all requirements.
• Bug free: Testing must be sufficient to have reasonable assurance that there are no major bugs in the software. If there are any remaining bugs, they need to be small, rare, and inconsequential.

Once the system passes functional testing, it is ready to follow a QA process to deploy the system. Once deployed, enhancements and bugs will lead to further development, which should follow the organization's SSDLC processes. This leads to another form of testing, which is regression testing.

Regression testing is done during the maintenance phase of software development to ensure that modifications to the software application (for example, to fix bugs or enhance the software) do not reduce current functionality, add new vulnerabilities, or reintroduce previous bugs and vulnerabilities that have been fixed.

By contrast, non-functional testing covers aspects of the system that are not directly related to the system's primary functions. For example, an online shopping application would undergo functional testing for features like user search, shopping cart management, and purchasing, since these are the main functions of a shopping app.

Non-functional requirements for the system might include support for encrypted connections, so users can safely share payment card information. This would be part of a system's security testing. The ability of the system to handle anticipated traffic volume is also important and is often done as part of load or capacity testing. Other non-functional testing can include compatibility testing across different platforms, as well as documentation testing to ensure that system documentation is properly updated when new functions or modules are released.

Testing is the way we obtain the confidence or assurance that our software is free of vulnerabilities and functions as required and designed. Testing allows for quality assurance. Adequate testing is important. This requires that adequate time be allocated to conduct testing to find, fix, and test again in an iterative process. In addition, automated testing tools can improve the efficiency and completeness of testing. In a continuous integration/continuous deployment (CI/CD) environment, automated testing becomes a required feature.

Security Testing Methodologies

Security testing is conducted to provide assurance that the organization's security strategy and architecture are followed and that all security requirements have been met. There are various methodologies for conducting software testing, and the approach will depend on several factors. The type of applications used by an organization will be one factor, as analyzing source code for entirely COTS-based software is likely impossible. Similarly, an organization utilizing only software as a service (SaaS) will be restricted from performing certain types of tests by the CSP, as the testing activity could disrupt other customers of the SaaS platform.

Quality Assurance

In a traditional development process, quality assurance (QA) was the testing phase. Separate from the development team, QA was the check before deployment that ensured that requirements were met and that the code was bug-free. QA was also part of the configuration management process, testing patches prior to deployment. In many organizations, that remains the role of QA.

The role of QA is significantly expanded in a DevOps or DevSecOps team, where QA is part of the process and is embedded throughout the development process. QA at this point isn't about the application service developed. Instead, QA is centered on service delivery of the software development function. QA occurs at each phase, ensuring continuous improvement and quality tracking. Testing is tied to both functional and security requirements developed in the requirements phase and specified by the security architecture and strategy. Because of the speed of modern DevOps, automated testing is heavily used, providing more frequent but potentially limited security testing capabilities.

For QA to be effective, further functional and requirements testing should be performed. QA should be involved in load testing, performance testing, stress testing, and vulnerability management. They may be a key part of tracking any identified security flaws from testing activities like SAST, DAST, or penetration testing.

In some DevOps environments, it is the QA team that pushes out the code once testing is completed. That team is responsible for ensuring that the code delivered to the customer through the cloud environment is quality code, defect-free, and secure. The QA team then takes a pivotal role in developing and delivering secure software and systems and is the final gate in the process of developing and delivering software.

Abuse Case Testing

Use cases are designed to test whether a system meets a defined requirement; e.g., a user logs in and must provide a username, password, and MFA code to gain access. Abuse cases are used to test the opposite of expected behavior. For example, what if a user put a SQL statement into the “password” field instead of their legitimate password? Would the application reject the input, maintaining security, or would it execute the SQL query and potentially lose confidentiality, integrity, or availability?

Abuse cases, sometimes known as misuse cases, are a key part of penetration testing and application security testing. Legitimate users may only perform functions in the expected manner, but attackers are unlikely to follow rules, since their objective is to circumvent those rules. Abuse case testing helps determine whether an application maintains security and responds correctly to unexpected inputs, behaviors, or attack attempts.

Securing Application Programming Interfaces

APIs provide a standardized way to access features or capabilities that a system offers. Unlike the user interface, which is accessed by an end user, APIs are typically accessed by other systems, some of which may be requesting data on behalf of an end user. These functions are exposed as endpoints, and many modern APIs are web-based and use standard HTTPs to communicate. Their modularity makes them popular in modern web and cloud applications, so securing them is important as they are likely to handle critical data.

API development and deployment in custom applications requires the same SSDLC as other software development projects. API functionality should be well documented in requirements, including security requirements such as supporting encryption. The requirements should also specify the methods used in the API to monitor access. API access monitoring is often done through authentication or keys. If not securely developed, a custom API can be vulnerable, leading to the compromise of the system it fronts. Deployment should focus on API configuration and automate the monitoring of that configuration.

APIs can control access to software or application services in a SaaS solution, to back-end services in a PaaS solution, or even to computing, storage, and other infrastructure components in an IaaS solution. For each of these, an approved API is important to ensure security to the system components with which we are interacting. In addition, when possible, enforcing the use of APIs to create a minimum number of methods for accessing an application service simplifies monitoring and protection of these application services.

A CSP or other vendor will provide an API or services that allow the use of an API. It is important to use the APIs as defined and to configure them carefully. An organization can develop approved configurations for APIs used commonly within that customer's organization, and policy can enforce the use of those standard configurations. Just as with cloud solutions, there is often shared responsibility for the security of APIs, so part of an SSDLC should include testing the configuration of any dependency applications and verifying the system configuration properly enforces API security.

In addition, vulnerability scanning of APIs can test the adherence to standards and can provide assurance that known vulnerabilities do not exist. It is impossible of course to ensure that unknown vulnerabilities such as zero-day vulnerabilities do not exist, so API testing should be supplemented with logging and monitoring to detect these threats.

Supply-Chain Management

There are two parts to supply chain risk management. First, it can refer to the needs of a CSP and potentially the customer to use third parties to provide services. For example, the CSP may rely on other vendors to provide services used by their customers. Management of this supply chain is a form of vendor risk management. When creating relationships with these vendors, both operational and security concerns should be addressed.

Additionally, traditional supply chain management is moving increasingly to the cloud. As the life of many organizations is tightly coupled with their supply chain management, the risks of cloud computing are important to consider. However, as the supply chain becomes increasingly global and sourcing of goods requires primary and secondary sources, cloud computing increases the reach and benefit of supply chain management. Cloud computing can optimize infrastructure to provide operational and financial benefits.

In recent years, supply chain risk has become an increasingly common theme. An earthquake in one country will affect the availability of a resource in another. Large-scale cyberattacks like the SolarWinds hack can impact critical infrastructure. A global pandemic leads to shortages worldwide. Even a simple problem, like a ship blocking the Suez Canal, can interrupt the global supply in unexpected ways.

One crucial part of supply chain risk management is assessing risk, which is similar to performing internal security risk assessments. Vendors may be assessed directly, where the organization performs a direct audit or assessment of the vendor's security posture. This is often done by sending the supplier a questionnaire, and several cloud-based SaaS providers exist to facilitate this information-gathering process.

Organizations with hundreds or thousands of customers may be incapable of supporting that volume of work. A third-party audit report is one solution. The audit report can be shared with customers as a method of assuring the security of data and systems that the organization provides. Common audits for this type of assurance include the Service Organization Controls (SOC) 2, Type II report, as well as ISO 27001 certifications.

Third-Party Software Management

The use of third-party software adds additional risk. A third party may have limited access to your systems but will often have direct access to some portion of your data. If this is sensitive data, a careful review is necessary and should involve the vendor management office (VMO) if your organization has one. Specific language regarding security should be part of every vendor contract.

The typical issues that are addressed include the following:

• Where in the cloud is the software running? Is this on a well-known CSP, or does the provider use their own cloud service?
• Is the data encrypted at rest and in transit, and what encryption technology is used?
• How is access management handled?
• What event logging can you receive?
• What auditing options exist?

In addition to basic security questions, a review of the third-party SOC-2 report, recent vulnerability scans and penetration tests, and security and privacy policies will provide an assessment of the security maturity of the organization and whether you should entrust them with your sensitive data. While you may delegate some processes, you cannot delegate responsibility for your data.

Licensing is another risk present to an organization using third party-supplied software. Software is typically licensed for use, and the terms of the license specify how the organization may utilize the software. One example is how many users can use the software. Some licenses apply to a “site,” which is often the entire organization; all users at the “site” can use the software. Other licenses are based on the number of users, such as one license per user or bands like 100–500 users.

Licenses may also specify how software may be used. Some software can be freely used and integrated into other software products, but some free and open-source software (FOSS) licenses prohibit the use of free tools in any for-profit system. License management may be integrated with the organization's SCA process to ensure that any software dependencies are being used in accordance with their license terms.

Validated Open-Source Software

All software, including open-source software (OSS), must be validated in a business environment. Some argue that open-source software is more secure because the source code is available to review, and many eyes are upon it. However, large and complex solutions are not simple to review, and the way OSS is integrated into any new application can introduce new vulnerabilities. Adequate validation testing is required and may be achieved through sandbox testing, vulnerability scans, and third-party verification.

While it is true that more eyes on a problem can result in better security outcomes, the transparent nature of OSS code is not an absolute guarantee of security. Well-known OSS projects like OpenSSL and Apache have contained serious vulnerabilities, and any systems that depended on these projects were impacted by the vulnerabilities. OSS must follow the same risk-based steps of verification that commercial software undergoes.

When using OSS, there are steps you can take to validate this resource. The easiest method is to use well-known and well-supported products in the OSS space. For example, there are many versions of Linux available for use, but not all versions are equal. A well-supported version with a proven track record is preferable to a less known and less supported version.

One method for validation that can be used would be to perform code analysis on the open-source code. The advantage of OSS is that the code is available, so SAST tools can be used to find security vulnerabilities in the code. Since not all vulnerabilities are tied to code flaws, IAST can be used in conjunction with SAST to identify other issues like system misconfiguration. An agent runs on the application server and analyzes traffic and execution flow to provide real-time detection of security issues.

These methods can also be utilized together. You can use a well-known and well-supported OSS, perform SAST to reveal initial vulnerabilities, and then implement IAST for real-time detection of additional security issues.

One element of SBOM is the ability to verify the integrity of software dependencies incorporated into a final system. This may be useful in deploying secure systems, as it provides assurance that the dependencies deployed in a system match the authentic copies distributed by the authors. A security breach in any part of the software supply chain can cause vulnerabilities in applications, so validating that authentic OSS modules are incorporated into an application is important.

Supplemental Security Components

Supplemental security components provide service to your cloud environment, and most are designed to solve specific security concerns. For example, database monitoring works to ensure the integrity of databases by blocking malicious transactions, while XML firewalls support application services by analyzing XML messages. Organizations must have an accurate inventory of cloud functions or features in use and select these supplemental components based on the security risk analysis for each.

Cryptography

Cryptography is a key technology for protecting sensitive data in the cloud. Encryption is the first line of defense for data confidentiality and provides a method of access control data crucial in cloud environments. Encryption requires the use of keys, and only users or systems with keys can read data. In the cloud, where physical control over IT infrastructure is given up, this allows users of cloud services to prevent other cloud tenants or the CSP from accessing their data.

There are three primary data states where encryption can be implemented: data at rest, data in motion, and key management.

Encryption for data at rest is a standard practice for all sensitive information. Many CSP services offer encrypted storage as a standard option. Some CSPs provide APIs that allow encryption to be added to any CSP service or customer application, and CSPs generally provide encryption options for their storage and database services. Some of these offerings utilize a CSP-managed key, but for high-security applications a user-generated and controlled key is needed.

Data-in-motion encryption is accomplished in standard ways including TLS, HTTPS, and VPNs. The ability to work with standard secure data transmission methods is supported across major CSPs and software like operating systems and web browsers. For securing data in transit between CSP data centers, the larger CSPs can accommodate data transfer without ever transiting the public Internet. However, this promise of not transiting the Internet does not necessarily mean that data is transiting a trusted network. Even when staying off the Internet, encrypted data transmission should be expected and may require proper configuration under the shared responsibility model.

Since encryption relies on keys, the generation, management, and secure sharing of those keys is a crucial practice. The major CSPs all provide key management services (KMS) as do some third-party vendors. Organizations must make a risk-based decision regarding a KMS. Solutions exist to allow the CSP to manage the keys, but for sensitive data it is preferable that the customer use their own KMS to improve key security. This can be achieved using an on-premises KMS solution, or utilizing a cloud-based KMS that is under the control of the customer and can be integrated with the CSP's solution, typically leveraging an API. This provides a separation of duties between the service managing the encrypted data and the service managing encryption keys.

Sandboxing

A sandbox is an environment with restricted connectivity and restricted functionality. Sandboxes provide security benefits by isolating potentially dangerous workloads, such as development environments, malware research, or untrusted applications. Cloud computing offers relatively simple sandboxing functionality, as new virtual instances can be created and isolated from all other services.

Sandboxes can be crucial in the SSDLC, by allowing developers to perform needed activities that might damage systems or data if done in a production environment. Code testing also benefits from an isolated environment like a sandbox. Any problems generated, such as a vulnerability that leads to a denial of service, will not impact anything outside the sandbox. This is also a suitable environment for developers new to cloud application development to try or test services provided by cloud providers without interfering with data integrity or confidentiality in the production application. This is a safe way to learn about and test cloud tools and services.

Sandboxes provide an environment for evaluating the security of code without impacting other systems. For example, many email security solutions open attachments in a virtual sandbox environment to perform security checks and scans. If the attachment is malicious, the sandbox contains the damage, but if it is benign, the user is allowed to open the attachment locally. Sandboxes can also be used for security testing activities like malware analysis or system security tests that could be harmful if performed in a live production environment.

Sandboxing is a common application security approach. Most desktop and mobile operating systems implement sandboxing for local applications, and many cloud-native architectures implement the concept as part of virtual machine (VM) isolation. When a new VM instance is created, it is isolated from communicating with anything else unless explicitly authorized, and network sandboxes can be created with virtual private clouds (VPCs), which isolate resources created inside them from other resources in the CSP.

Application Virtualization and Orchestration

Virtualization of infrastructure is an essential core technology for cloud computing, and there are several approaches to application orchestration and virtualization. One approach is microservices, which are small and independent services that communicate to share and handle data. Communication is typically API-based, and the microservices are specialized to perform a limited set of functions.

An application that is broken down into microservices is not truly virtualized, but deploying the various microservices needed requires coordination and orchestration. The microservices that make up an application can be updated independently, but orchestrating those updates is critical to ensure that needed functionality is not broken or removed.

Application virtualization through containers allows an application to be packaged with all dependencies together and deployed on any system that supports the container technology used. This makes applications more portable since they are not specifically tied to the underlying system architecture and may be useful for implementing a multi-cloud strategy.

Containers provide a method for implementing security control, since they can be subject to strict configuration management and patch management and offer an automated and repeatable build process.

Container technology and orchestration typically require a combination of tools. Docker is one popular containerization platform, while Kubernetes is a popular orchestration platform. The orchestration tool provides the ability to manage container resources, manage configurations, and monitor the configuration of containers to ensure that they align with organization policies.

Containers do not come without a cost. The containerization technology used must be properly configured, and as a software system it is important to ensure that it is properly patched. If the technology is compromised, so is the container; while the container platform provides a single point of implementing security controls, it can also be a single point of failure if a vulnerability exists. Any orchestration software must also be configured and patched.

Separate from container orchestration, cloud orchestration allows a customer to manage their cloud resources centrally in an efficient and cost-effective manner. This is especially important in a multi-cloud environment. Management of the complexity of corporate cloud needs will only increase as more computing workloads move to the cloud. Cloud orchestration allows the automation of workflows and management of accounts and the deployment of cloud applications, containerized applications, and services in a way that manages cost and enforces corporate policy in the cloud. The major CSPs offer orchestration tools that work within their cloud environment, and third-party tools can be used for orchestrating complex, multi-cloud workloads.

Applications can be “containerized” as well, and this is often implemented as part of mobile device management (MDM). In this case, the container creates an isolated environment on a user's device where the application can run and over which the organization has control. This is often used for segregating organizational data from user data in a bring-your-own-device (BYOD) environment. The container can be configured to follow specific access controls like using a VPN, restrict transfer of data to nonapproved apps, and even provide the organization with remote data wiping capabilities for lost or stolen devices.

Federated Identity

Federated identity, sometimes known as federated identity management (FIM), is related to single sign-on (SSO). In a federated identity setup, a particular digital ID allows access across multiple systems—the various systems that rely on the digital ID provider are federated with that provider. In a FIM system, a user has a single digital ID and authentication credentials, which grant access to applications across both cloud and on-premises resources.

Federation allows SSO for systems across multiple organizations and is often used for sharing resources with partners or other organizations. These may be subsidiaries of the same company, multiple CSPs, cloud vendors, or multiple organizations.

Although it provides benefits, there are security risks to FIM. The primary issue is that once someone compromises a digital ID in a federated system, the ID is compromised on all systems that are federated. This makes the security of the IAM itself a critical concern, and typical controls include increased access control to the IAM itself, as well as robust monitoring for malicious use. Although a compromised FIM account can be a serious security risk, the ease of revoking access across federated systems is a security benefit. Instead of disabling access to multiple systems, security responders can simply disable an account in the FIM tool, cutting off an attacker's access across all federated systems.

Other drawbacks to identity federation are similar to SSO. The level of trust between systems owned by multiple organizations may not be the same as between systems of a single organization. Just as with any other system interconnection, the organization must assess the risk of federating identity management with another organization’s systems. Additionally, no organization controls the system protection across all organizations or the evaluation of all users in each organization, which can lead weak access controls in one organization to impact others.

Identity Providers

An identity provider (IdP) can be a CSP service or a service acquired from a third party. Many identity as a service (IDaaS) providers exist, and in a multi-cloud environment these may be the best choice since they are platform agnostic and designed for easy integration across different CSPs. Identity providers do not replace other cloud security tools, such as a Cloud Access Security Broker (CASB), but work together to provide a layered security defense based on user, system, and account identity management. The IdP is a key part of the IAM solution, ensuring that users are identified and authenticated. Authorization and monitoring of access may be provided by other tools like a CASB or application-specific audit logging and a log analysis tool.

The major CSPs provide IAM services, including Azure Active Directory (Azure AD), AWS Identity and Access Management, and Google Cloud Identity and Access Management. There are also many third-party choices for identity management. Each organization should evaluate its cloud strategy and choose an IdP to match it. For example, an organization that is cloud native with multiple SaaS providers will likely benefit from an IDaaS solution, while an organization with on-premises Microsoft infrastructure and Azure-based cloud resources might find Azure AD to be the best tool, since it is well-designed for the existing infrastructure. As with all security tools, the choice of an IdP should be done with business objectives and requirements in mind.

Single Sign-on

Single sign-on (SSO) allows access to all authorized systems that fall under a single IAM system and only require users to assert an identity and authenticate once. The user can move freely between systems without having to reauthenticate each time, similar to a theme park where visitors can purchase a ticket to enter and move freely about the park without waiting in line to buy another ticket.

An SSO is a centralized resource and can be a single point of failure. It is important to monitor all access within an SSO system, since a compromised account can be used to gain access to all systems that integrate with the SSO. Availability is also a key concern for the SSO, since the system being unreachable will lead to users locked out of all integrated applications.

The primary advantage of an SSO is limiting the number of credentials a user must manage, which can be used to increase the strength of access controls like passphrases. Instead of remembering 10 passwords, a user is required to remember only one, so the organization can more easily ask for increased complexity. In the event of an account compromise, the centralized nature of an SSO also makes recovery easier—only one set of credentials must be changed to block an attacker from further access. The SSO allows for simpler central monitoring and access maintenance as well. When each system implements its own IAM functions, monitoring is more complex, and if a user's access must be modified or removed, the increased complexity can lead to errors or oversights.

SSO evolved with a focus on simplifying internal access management, but extending SSO across systems controlled by other organizations is an example of federation. Federation increases the risk caused by a compromised identity, as the number of systems that may be compromised is greater. However, it also offers a more powerful response to compromised accounts, with decreased complexity required in responding to the compromise. Just as with a FIM, an SSO should be a crucial part of continuous monitoring, and incident response procedures should be developed and documented for responding to malicious activity.

Multifactor Authentication

Multifactor authentication (MFA) adds a level of security to standard authentication, by requiring users to provide additional proof of their identity. Two-factor authentication (2FA) and MFA are often used interchangeably. 2FA requires two authentication factors, while MFA requires two or more, so 2FA is a subset of MFA.

Authentication is performed when users provide something that confirms their identity, known as factors. The factors are categorized by types:

• Type 1, Something you know: This includes answers to security questions, identification of previously selected photos/pictures, PINs, passphrases, and passwords.
• Type 2, Something you have: Examples include a hardware token, smartphone, or a card, such as a debit card or smart card. Authentication is achieved when the user proves they have possession, such as by presenting the card or entering a code generated by a hardware token or authenticator app.
• Type 3, Something you are: This category generally refers to biometrics, which are measurements of biological characteristics such as fingerprints, facial recognition, or iris scans. Of the three, these are the most challenging to do reliably and at a reasonable cost, although the prevalence of fingerprint and facial geometry hardware on modern smartphones has increased the viability of biometric authentication.

A fourth authentication factor is beginning to emerge: characteristics of the user request. Factors such as signing in from a previously used device are part of this authentication decision. If a user signs in from the same trusted device every day, the use of that device provides some assurance of the user's identity. The same user credentials entered from a new device or different location, however, indicate a potential security risk. If the user has received a new laptop, the access is legitimate, but if the user's account has been compromised, then it is beneficial to deny access. These types of policy-based authentication schemes can be used to require additional MFA steps for suspicious access, providing a balance between irritating normal users with cumbersome logins and protecting sensitive accounts.

Some solutions described as MFA are simply multiple instances of the same factor, which is not true MFA. An example is when a system requires a user ID, a password, and the answer to a security question—these are all things you know. This is single-factor authentication since it relies on only Type 1 factors; to be true MFA, another factor such as the user's IP address (Type 4) or sign-in from a trusted device (Type 2) must be added.

One use of MFA is to limit the potential damage caused by a compromised account in an SSO or federated system, and MFA deployed here is a compensating control for the risk of a single compromised account granting access to multiple systems. If, when moving from one federated system to another or one federated resource to another, a token is required from something you have, then the ease of SSO or federation is decreased slightly while increasing security. The method chosen will be a balanced decision based on available options, the cost of available options, the value of the asset being protected, and the organization's risk tolerance.

Another approach would be to simply require a token from a device periodically throughout the day, for example, every two hours. This limits the time a compromised identity can be used. The additional burden of authenticating two to three times a day may be an acceptable price to pay to limit the damage of a compromised identity in a federated or SSO environment.

Cloud Access Security Broker

A CASB is an important addition to cloud security and helps to solve challenges related to multiple systems with varying access control models and abilities. A CASB sits between the cloud application or server and the users and may be software- or hardware-based. The CASB monitors activity, enforces security policies, and mitigates security events through identification, notification, and prevention. A part of a layered security strategy, a CASB is not meant to replace firewalls, IDS/IPS systems, or similar security systems. Instead, a CASB is meant to enhance the security provided by these other devices.

A CASB that provides security must be in the line of communication that users follow to reach the application. In on-premises architecture this type of task was easy, with a single network inside a facility where monitoring tools could be attached. Multi-cloud organizations with distributed teams will find this task more complicated, since a user in an office and a user working from home will take different paths to reach cloud-based resources. Architecting and deploying an appropriate CASB solution requires deep knowledge of the environment and use cases, such as support for remote work and need to access one or more cloud environments.

CASBs may be agent-based or agentless, referring to a software agent deployed on computing devices. In either case, they must be inline on the communications paths in order to function as a preventative control. There are also out-of-band CASBs that receive copies of cloud traffic for security analysis, which can be deployed as a reactive control since they do not have the ability to proactively block traffic. These are somewhat analogous to an IPS and an IDS. The inline CASB analyzes requests and enforces policy, like an IPS, blocking suspicious activity when detected. An API-based, out-of-band CASB monitors for violation and analyzes cloud traffic and can generate alerts once suspicious activity has occurred.

Agent-based CASBs may face pushback from users in BYOD organizations. When the user owns the device, it may not be possible to install an agent on the device, and not all CASBs support the wide variety of mobile devices and platforms. Similar to antimalware agents, an agent-based CASB may impact device performance such as speed or battery life. When the organization owns the devices, an agent-based approach can be more effective, and containerized apps may provide a way to implement security controls on BYOD without as much impact.

An agentless CASB typically uses an API on the cloud resources to inspect all traffic to and from that resource, granting the CASB access to logs of activity for analysis. This allows access to all cloud resources to be monitored regardless of endpoint ownership and regardless of cloud service, so long as an API is available. Agentless CASBs can be quickly deployed and more easily maintained but lack the proactive detection and response capabilities of an agent-based solution.