CompTIA CASP+ CAS-004 Certification: A Simple Guide To Security Activities Across Technology Lifecycle

When it comes to managing an enterprise’s security, security practitioners must consider security throughout the whole technological life cycle.
Security practitioners must ensure that the necessary security controls are installed as the company evolves as new devices and technologies are added, maintained, and removed.

Understanding the systems and software development life cycles, adapting solutions to handle evolving risks, disruptive technologies, security trends, and asset management are all part of providing security across the technology life cycle.


Topics:

- System development lifecycle
- Secure software development
- Asset inventory and control
- Adopting disruptive technologies

Structure
- Systems and software development life cycle
- Adapt solutions
- Asset management

Objectives
The requirements for systems development, acquisition, testing and evaluation, commissioning/decommissioning, operating operations, asset disposal, and asset/object reuse are all covered in this guide.

Application security frameworks, software assurance, development methodologies, DevOps, secure coding standards, documentation, and validation and acceptance testing are all terms used to define software development.

Emerging threats, disruptive technology, and security trends are discussed by Adapt Solutions.

Asset management, inventory control, and related ideas are all part of asset management or inventory control.

Systems development life cycle
When a company defines new functionality that it must supply to consumers or internally, it must develop systems to deliver that functionality. Many judgments must be made, and those decisions must be made using a rational procedure. The systems development life cycle (SDLC) is the name for this procedure.

The SDLC, rather than being a random method, offers clear and logical stages to guarantee that the system that emerges at the conclusion of the development process provides the expected functionality while maintaining an acceptable degree of security, as shown below:


Figure: Systems Development Lifecycle

The steps in the SDLC are as follows:
 

- Initiate/plan
The perception that new features or functions are needed or required in the company occurs during the start phase. This new feature might be an upgrade to an existing asset, or it could be the purchase or creation of a brand new asset. Choosing whether to buy the product or develop it internally is part of the initial step. A company must also consider the solution’s security needs at this point.

The CIA’s needs and concerns can be detailed in a preliminary risk assessment. It’s critical to identify these difficulties early on so that these factors can drive the solution’s procurement or development. The sooner security requirements are identified in the SDLC, the more likely they are to be addressed effectively in the final product.

- Acquire/develop
A set of actions in the SDLC’s acquisition stage give information to help decide whether to buy or build the solution. After that, the organization chooses a solution.

The activities are designed to get answers to the following questions:
- What functions does the system need to perform?
- What potential risks to the CIA are exposed by the solution?
- What protection levels must be provided to satisfy legal and regulatory requirements?
- What tests are required to ensure that security concerns have been mitigated?
- How do various third-party solutions address these concerns?
- How do the security controls required by the solution affect other parts of the company’s security policy?
- What metrics will be used to evaluate the success of the security controls?

The answers to these questions should guide the questions during the acquisition step as well as the steps that follow this stage of the SDLC.

- Implement/design
Before the system goes online, top management formally authorizes it during the implementation stage. The solution is next deployed in a real environment, which is known as the operation/maintenance stage—but only when the company has accomplished both certification and accreditation. The process of certifying a solution’s efficacy and security is known as certification. The management must give an official approval to bring the solution into the production environment as part of the certification procedure. The security administrator would teach all users how to secure corporate information when using the new system, as well as how to spot social engineering threats, at this time.

- Operate/maintain
When the system is turned on and started in the environment, the procedure does not finish there. It’s crucial to establish a performance baseline so that ongoing monitoring can take place. The baseline guarantees that performance problems may be identified promptly. Any changes over time (for example, new features, solution patches, and so on) should be regularly monitored for their impact on the baseline. By establishing a systematic change management procedure, you can ensure that all modifications are authorized and recorded. Because any modifications might have an impact on both security and performance, it’s important to pay close attention to the solution once any changes are made.

- Dispose
Finally, when the solution has been deployed, vulnerability assessments and penetration testing can help identify any security or performance issues that may have been caused by a change or occur as a result of a new threat. When the solution has served its purpose, the disposal stage involves removing it from the environment.

When this occurs, an organization must consider certain issues, including the following:
- Does removal or replacement of the solution introduce any security holes in the network?
- How can the system be terminated in an orderly fashion so as not to disrupt business continuity?
- How should any residual data left on any systems be removed?
- How should any physical systems that were part of the solution be disposed of safely?
- Are there any legal or regulatory issues that would guide the destruction of data?

You must know how to cover the SDLC from the beginning to conclusion in order to pass the CASP test.

Consider a corporation that wishes to increase earnings by cutting costs on non-core business operations. The IT manager requests clearance to move the company’s email system to the cloud. Data life cycle concerns must be taken into account by the compliance officer. Data provisioning, data processing, data in transit, data at rest, and de-provisioning would represent the end-to-end data life cycle in this scenario.

Requirements
One of the tasks that occurs during the acquisition stage of the SDLC is the definition of system requirements. The purpose of this procedure is to guarantee that the system can execute all intended activities and that no resources are wasted on unnecessary functionality. Security needs are also established at this stage, which are driven by the needed functionality and the expected sensitivity of the data to be handled by the system. These criteria must be recognized early in the development process and included into the system design.

Acquisition
A system may be acquired rather than constructed in many circumstances, or a portion of a planned system may require acquisition. Before issuing any requests for bids, security specialists must be involved in determining the security criteria for the equipment to be procured when issuing some request for proposals or RFPs.

Test and evaluation
Several sorts of testing, including approaches to uncover both functional problems and security vulnerabilities, should take place throughout the test and assessment phase. The test data method is an auditing approach that determines the amount of system testing and identifies specific program logic that has not been tested. This approach assesses the behavior of the program in both cases by testing not only anticipated or legitimate input, but also incorrect and unexpected data. Assaults on the program should be made actively, including buffer overflows and denial of service (DoS) attacks.

Commissioning/decommissioning
The process of commissioning an asset is the process of integrating it into an organization, whereas the process of decommissioning an asset is the process of removing it from service. When an asset is put into production, it should be protected with the proper security measures. These security controls might be placed on the asset itself or on an enterprise asset like a firewall or router. When an asset is decommissioned, it is critical that the data held on the asset be safeguarded. Sometimes an asset is retired temporarily, while at other times, it is permanently decommissioned. Regardless of the situation, it is critical to follow the right asset disposal and asset reuse policies to protect the organization’s confidentiality, integrity, and availability. In most circumstances, you’ll need to back up all of the data on a decommissioned asset and make sure it’s totally deleted before disposing of it. These rules should be reviewed and modified on a regular basis, especially when new assets or asset kinds are introduced to the company.
 

Consider the following scenario. Assume an information security officer (ISO) requests a security crew to go through the warehouse trash bin and gather abandoned PCs at random. Two outdated PCs and a faulty multi-function network printer are retrieved by the security team. The security team connects the two PCs’ hard discs as well as the network printer to a computer with forensic tools. They are able to view the PDF files on the network printer hard drive, but not the data on the two older hard drives. The warehouse management should alter the hardware decommissioning processes as a result of this discovery to address the security problem.

Let’s take a look at another scenario. Assume that a new vendor product has been purchased to replace an older one. Due to the present solution’s near-end-of-life status and the lack of choices for prolonged support, there are significant timing restrictions. It has been stressed that only critical actions be completed for this project. You should test the new solution, migrate to the new solution, and then decommission the old system to strike a balance between security and time restrictions.

Operational activities
For example, an organization may have a policy in place that prevents the use of any wireless technology at the enterprise level. If a new device or technology requires wireless access, the organization will need to revisit the security policy to allow wireless access. However, the organization must ensure that the appropriate security controls are implemented when wireless access is added to the enterprise. Performing a security impact analysis involves examining the impact of the new functionality, application, or system on the organization’s confidentiality, integrity, and availability. Operational activities are daily tasks performed with the use of a gadget or technology.

All operational operations must be protected, and security controls must be checked on a regular basis to verify that they are still providing protection. While day-to-day operations are included, operational activities also involve the addition of new functionality, new applications, or entirely new systems to the infrastructure. Any new introduction, regardless of its nature, poses a risk to the company. As a result, security professionals must conduct a risk assessment and implement the necessary security measures to limit threats. An organization’s security policy may be impacted by the addition of functionality, an application, or a system.

Security awareness and training are critical for ensuring the security of day-to-day operating activities. As new threats emerge, security awareness and training should be updated. Employees should go through this training when they first start working and at least once a year after that.

Monitoring
Once a system is up and running, it should be checked for security and performance problems. It’s critical to establish a performance baseline so that ongoing monitoring can take place. The baseline guarantees that performance problems may be identified promptly. Any changes over time (for example, new features, solution patches, and so on) should be regularly monitored for their impact on the baseline. Significant changes may necessitate the construction of a new baseline in many circumstances, as the previous baseline may no longer be indicative of the current status quo. By establishing a formal change management process, you can ensure that all changes are approved and documented.

Because any modifications might have an impact on both security and performance, it’s important to pay close attention to the solution following any changes, as shown below:


Figure: Dashboard for system monitoring

Finally, when the solution has been deployed, vulnerability assessments and penetration testing can help identify any security or performance issues that may have been caused by a change or occurred as a result of a new threat.

Maintenance
Patches, hotfixes, security updates, and service packs must all be maintained up to date for systems to function properly. Before releasing an update into production, it should be thoroughly tested in a lab setting. It is constantly vital to examine the security measures in place and to adopt any new controls when risks are found when maintenance is performed. Both hardware and software require maintenance, and both are equally critical in a maintenance strategy. Even if a device or a program is not utilized as frequently as others, it is still subject to timely updates.

Hardware and software updates can frequently have unintended repercussions. Because the program interacts in a new way, a new application update may produce false positives on the corporate firewall. Ignoring a false positive (or turning off the warning) isn’t enough. Security professionals should do studies on issues like these to identify the best course of action.

Another effect of an update might be that it introduces problems that can’t be fixed at the time of distribution. It may be essential to restore the hardware or software to its prior state in this situation. It is critical, however, that the update not be overlooked. A strategy should be put in place to guarantee that the update is deployed as soon as feasible.
It may be essential to reassign staff to guarantee that the issue is investigated and the update is re-deployed. Let’s look at an example of maintenance and how it affects security.

Let’s say the chief information security officer (CISO) asks the IT manager who was responsible for the system upgrade after it causes considerable disruption. The IT manager says that because five separate persons have administrative access to the system, determining who is responsible is impossible. The IT manager should establish an enforceable change management system and allow user-level audits on all servers to boost responsibility and avoid this problem from recurring. Any maintenance program should contain documentation of all maintenance operations, including the person who performed the work, the type of work performed, the outcome of the work, and any issues that emerged, as well as issue resolution notes. This material will serve as a roadmap for the future.

Configuration and change management
Technology evolves, grows, and changes over time. Examples of changes that can occur include the following:
- Operating system configuration
- Software configuration
- Hardware configuration

Companies and their processes adapt and change as well, but change should be handled in a controlled manner to retain a shared sense of purpose. Change may be avoided from becoming a problem by following prescribed stages in a structured process. Keep in mind that change management collaborates with configuration management to guarantee that asset modifications do not accidentally compromise security. As a result, all modifications must be recorded, and all network diagrams, both logical and physical, must be updated on a regular basis to correctly represent the current configuration of each asset rather than the configuration two years ago. It should be a continuous activity to ensure that all change management policies are followed.

Consider the following scenario. Consider a corporation that has over 13,000 client PCs and 1,400 server machines. The IDS is sending many alarms to the security administrator about a probable virus spreading over the network via the Windows file sharing service. The security engineer feels that blocking the file-sharing service across the enterprise using access control lists (ACLs) on internal routers is the best course of action. To guarantee that the ACLs do not disrupt critical business operations, the company should convene an emergency change management meeting. In many circumstances, forming a change control board is advantageous.

The tasks of the change control board can include the following:
- Ensuring that changes made are approved, tested, documented, and implemented correctly
- Meeting periodically to discuss change status accounting reports
- Maintaining responsibility for ensuring that changes made do not jeopardize the soundness of the verification system

Configuration management, while a subset of change management, focuses on bringing order to the chaos that can arise when different engineers and technicians have administrative access to the computers and devices that make the network run. It follows the same fundamental change management approach as before, but it may be even more important given the impact that competing changes might have on the network (in some cases instantaneously).

Configuration management includes the following functions:
- Report the status of change processing.
- Document the functional and physical characteristics of each configuration item.
- Perform information capture and version control.
- Control changes to the configuration items and issue versions of configuration items from the software library.

A software library is a regulated location available only to authorized users who are restricted to using an approved method in the context of configuration management. A configuration item (CI) is a discrete component of the system that is subject to its own configuration management mechanism. Configuration identification is the process of breaking down an operation into discrete CIs. The most important contribution of configuration management controls is ensuring that system modifications do not inadvertently compromise security.

Asset disposal
When an organization decides that an asset will no longer be utilized, it disposes of it. The business must guarantee that no data is left on the asset during disposal. Degaussing, which includes subjecting the media to a high alternating magnetic field, is the most dependable and secure method of extracting data from magnetic storage media, such as a magnetic hard drive. Degaussing clears the medium of all previously written data, leaving it magnetically randomized (blank). According to Department of Defense (DoD) Instruction 5220.22, functional hard discs should be rewritten three times before being discarded or reused.

According to NIST Special Publication, modern hard drives can resist traditional forensic recovery after a single wiping pass (SP).

Keep in mind that encrypting data on a hard disc renders the data unrecoverable without the encryption key, assuming the encryption mechanism isn’t compromised. This is the most effective solution for data protection across all media types.
Assume a business intends to give 1,200 used computers to a local school. Some of the machines were previously utilized to store private research data in the company’s vast research and development department. Data leftovers on donated devices should be a worry for the security administrator. If the company’s data handling policy does not include a device sanitization clause, the best course of action for the security administrator is to postpone the donation until all storage media on the PCs has been sanitized. An organization should also make certain that an item is properly disposed of, in accordance with local, state, and federal rules and regulations.

Asset/object reuse
When a company intends to repurpose an asset, it should do a detailed examination of the asset’s original and new uses. If the asset will be utilized in the same way, superfluous programs or services may merely need to be removed or disabled. It may, however, be essential to revert the asset to its factory settings. If the asset has a hard drive or another storage medium, it should be completely wiped of all data, particularly if it includes sensitive, private, or secret information.

Software development life cycle
The software development life cycle is a subset of the systems development life cycle, in that any system in development may (but is not required to) contain software development to support the solution. The software development life cycle’s purpose is to create a predictable framework of methods for identifying and ensuring that all criteria for functionality, cost, dependability, and delivery schedule are satisfied in the final product.

The figure below shows how this section breaks down the processes in the software development life cycle and explains how each one contributes to the end objective; remember that the processes in the software development life cycle vary depending on the provider, and this is just one example:


Figure: Software development lifecycle

The following sections flesh out the software development life cycle steps in detail:
Step 1: Plan/initiate project
Step 2: Gather requirements
Step 3: Design
Step 4: Develop
Step 5: Test/validate
Step 6: Release/maintain
Step 7: Certify/accredit
Step 8: Change management and configuration management/replacement

Plan/initiate project
The organization chooses to start a new software development project and formally plans it at the plan/initiate step of the software development life cycle. Security experts should be consulted in this phase to assess if the project’s data needs to be protected and whether the application itself needs to be protected independently from the data it processes. Security specialists must examine the predicted outcomes of the new application to evaluate whether the resulting data is more valuable to the company and, as a result, requires more security. Any data processed by the program requires a value provided by its owner, as well as documentation of any unique regulatory or compliance requirements. Healthcare information, for example, is governed by various federal regulations and must be safeguarded. The classification of all input and output data for the application, as well as the required application controls to guarantee that the input and output data are safeguarded, should be documented. The sorts of networks utilized in data transmission must also be determined. All data sources must be scrutinized. Finally, the application’s impact on organizational operations and culture must be evaluated.

Gather requirements
The functionality and security needs of the solution are identified during the gather requirements phase of the software development life cycle. These criteria might come from a variety of places, such as a competitive product evaluation for a commercial product or a user survey for an internal solution. These needs might originate from a direct request from a present customer in some situations. Organizations must assess possible weaknesses and threats from a security standpoint. When performing this assessment, keep in mind the software’s intended function as well as the expected environment. Furthermore, the sensitivity of the data that the solution will create or manage must be evaluated. It could be beneficial to assign a privacy effect rating to the data in order to advise efforts to prevent the data from exposure.

Design
An organization produces a clear description of how the software will fulfil all functional and security goals throughout the design phase of the software development life cycle. It entails mapping the software’s internal behavior and operations to specified criteria in order to detect those that have not been satisfied prior to installation and testing. Throughout this procedure, the application’s state is determined at each stage of its operations. During each operation, the state of the application refers to its functional and security posture. As a result, all conceivable activities must be identified in order to guarantee that the program never becomes vulnerable or behaves in an unpredictable manner. This study also includes determining the attack surface. An attacker’s attack surface defines what resources are available to them. At different stages of the application, the quantity of attack surface offered may fluctuate, but at no point should the attack surface provided contradict the security needs defined in the gather requirements stage.

Develop
The code or instructions that make the software work are written during the development phase. This phase is focused on ensuring that secure coding techniques are followed to the letter. Insecure coding techniques, such as the lack of input validation or data type checks, cause many software security concerns. These flaws must be identified via a code review that aims to anticipate all conceivable attack scenarios and their consequences for the code. Buffer overflows, injection, and other incorrect circumstances can occur if these problems are not identified.

Test/validate
Several sorts of testing should take place throughout the test/validate phase, including finding both functional and security concerns. The test data method is an auditing approach that determines the amount of system testing and identifies specific program logic that has not been tested. This approach assesses the behavior of the program in both cases by testing not only the anticipated or legitimate input, but also incorrect and unexpected data. An aggressive attempt at hacking the program should be performed, including buffer overflows and denial-of-service (DoS) attacks.

Some types of testing performed at this time are as follows:
- Verification testing: Determines whether the original design specifications have been met
- Validation testing: Takes a higher-level view and determines whether the original purpose of the software has been achieved

Release/maintain
The introduction of the program into the live environment, as well as ongoing monitoring of its operation, are part of the release/maintenance phase. It’s fairly uncommon to discover additional functional and security issues as the program begins to communicate with other network parts at this stage. In many circumstances, vulnerabilities in live settings are uncovered for which there is no current fix or patch. A zero-day vulnerability is what it’s called. Supporting development employees should, ideally, find such flaws before those seeking to exploit them do.

Certify/accredit
The process of reviewing software for its security efficiency in relation to the customer’s demands is known as certification. Ratings can obviously help, but they aren’t the only factor to consider. Management’s official acknowledgment of the suitability of a system’s overall security is known as accreditation. Provisional accreditation is granted for a certain period of time and it includes a list of needed adjustments to applications, systems, or accreditation paperwork. Full certification means that there are no adjustments that must be made. Once all of the revisions have been performed, assessed, and authorized by the certifying authority, provisional certification becomes full accreditation. While certification and accreditation are connected, they are not thought to be two separate phases in the same process.

Change and configuration management
Following the deployment of a solution in a live environment, more changes to the software will surely be required due to security concerns. The software may be changed in some circumstances to improve or expand its capabilities. Changes must be managed using a proper change and configuration management approach in any scenario.

The goal of this procedure is to guarantee that any modifications to the source code’s configuration and implementation are approved by the appropriate persons and carried out safely and rationally. This approach should always assure continuing operation in the live environment, and all modifications, including hardware and software changes, should be completely documented. It may be required to replace apps or systems entirely in some circumstances. While some errors may be rectified with additions or tweaks, some may necessitate a total replacement of the program.

Application security frameworks
Various frameworks have been designed to assist the secure development of apps in an attempt to introduce some consistency to application security. These tools and frameworks help alleviate a lot of the tedium that comes with secure coding.

Software assurance
Regardless of whether the software was built in-house or purchased commercially, security specialists must guarantee that the program is not only functional but also secure. There are two approaches to this – audit the program’s activities to see whether it conducts any insecure actions or evaluate it using a formal procedure.

Auditing and logging
Continuous auditing of the software’s activities and regular examination of the audit data is a technique and a practice that should be continued once it has been introduced to the environment. Security flaws that may not have been obvious at the outset or that may have gone unnoticed until now can be found by monitoring audit logs. Furthermore, any modifications performed will be documented in the audit log, which can later be verified to ensure that no security vulnerabilities were introduced as a result of the change.

Risk analysis and mitigation
Risk management must be included in any software development since it is a continuous process. Risk analysis identifies potential hazards, whereas risk mitigation is taking efforts to mitigate the consequences of such risks.

The following guidelines must be implemented by security experts while analyzing and mitigating software development risks:
- Integrate risk analysis and mitigation in the software development life cycle.
- Use qualitative, quantitative, and hybrid risk analysis approaches based on standardized risk analysis methods.
- Track and manage weaknesses that are discovered throughout risk assessment, change management, and continuous monitoring.

Since software frequently contains vulnerabilities that aren’t found until it’s in use, security experts should make sure that a patch management procedure is established and deployed as needed to mitigate risk. Using a change control procedure, testing any patches, maintaining a functional backup, scheduling production downtime, and having a back-out strategy are all examples of this. Help desk workers and critical user groups should be alerted before any fixes are deployed. Patches should be applied to the least critical computers and devices first, progressing up the hierarchy until the most critical systems and devices are patched.

After mitigations have been implemented, they must be validated and confirmed, which is normally done as part of quality assurance and testing. Any risk mitigation that has been performed must be confirmed by a third party that isn’t the creator or owner of the system.

Code signing should be promoted among developers to maintain code integrity, verify who wrote the code, and determine the code’s purpose. Code-signing certificates are digital certificates that guarantee that a piece of code has not been tampered with. Organizations can identify if the code has been updated by someone other than the signer by signing it. Program signing is primarily concerned with running code rather than stored code. While code signing confirms code integrity, it does not ensure that a program is devoid of security flaws or that it will not execute unsafe or unmodified code.

Regression and acceptance testing
Regression and acceptability testing are required for any software updates or additions. Regression testing ensures that the program performs as expected. Regression testing identifies issues that may have been introduced inadvertently into a new build or release candidate. Acceptance testing ensures that the product performs as expected by the user. Acceptance testing is more formal and involves assessing the functioning of a product for users based on a user narrative.

Security impact of acquired software
Commercial software is frequently purchased, and businesses frequently contract with other firms to produce bespoke software. Security specialists must ensure that the business is aware of the security implications of any software it acquires.

The four steps of the software acquisition process are as follows:
- Planning: During this phase, the organization performs a needs assessment, develops the software requirements, creates the acquisition strategy, and develops evaluation criteria and plans.
- Contracting: Once planning is completed, the organization creates an RFP or other supplier solicitation forms, evaluates the supplier proposals, and negotiates the final contract with the selected seller.
- Monitoring and accepting: After a contract is in place, the organization establishes the contract work schedule, implements change control procedures, and reviews and accepts the software deliverables.
- Follow-on: When the software is in place, the organization must sustain the software, including managing risks and changes. At some point, it may be necessary for the organization to de-commission the software.

Security professionals should be involved in the software assurance process. This process ensures that unintentional errors, malicious code, information theft, and unauthorized product changes or inserted agents are detected.

WASC
The Web Application Security Consortium (WASC) is a non-profit organization that promotes best practices for web-based apps, as well as a number of resources, tools, and information that businesses may use to create them. WASC keeps track of attacks and has compiled a list of the most common attack tactics. This list can help an organization stay on top of the most recent attack tactics and how pervasive they are. It can also help a business make the necessary adjustments to its online applications to prevent these sorts of attacks.

OWASP
Another organization that monitors assaults, especially web attacks, is the Open Web Application Security Project (OWASP). OWASP keeps track of the top ten assaults on a regular basis. This organization also has monthly meetings in chapters all around the world, where they provide resources and tools like testing processes, code review stages, and development guidelines, as shown below:



Figure: OWASP Top10 2021 vulnerabilities
 

The figure above shows presents the top 10 Web application-related vulnerabilities for 2021, which presents the standard for reference to perform security tests on the following critical issues:

- A01:2021-Broken Access Control moved up from the fifth position to the category with the most serious web application security risk; the contributed data indicates that on average, 3.81% of applications tested had one or more Common Weakness Enumerations (CWEs) with more than 318k occurrences of CWEs in this risk category. The 34 CWEs mapped to Broken Access Control had more occurrences in applications than any other category.
- A02:2021-Cryptographic Failures shifted up one position to #2, previously known as A3:2017-Sensitive Data Exposure, which was a broad symptom rather than a root cause. The renewed name focuses on failures related to cryptography as it has been implicitly before. This category often leads to sensitive data exposure or system compromise.
- A03:2021-Injection slid down to the third position. 94% of the applications were tested for some form of injection with a max incidence rate of 19%, an average incidence rate of 3.37%, and the 33 CWEs mapped into this category have the second most occurrences in applications with 274k occurrences. Cross-site scripting is now part of this category in this edition.
- A04:2021-Insecure Design is a new category for 2021, with a focus on risks related to design flaws. If we genuinely want to “move left” as an industry, we need more threat modeling, secure design patterns and principles, and reference architectures. An insecure design cannot be fixed by a perfect implementation, as by definition, the needed security controls were never created to defend against specific attacks.
- A05:2021-Security Misconfiguration moved up from #6 in the previous edition; 90% of applications were tested for some form of misconfiguration, with an average incidence rate of 4.5%, and over 208k occurrences of CWEs mapped to this risk category. With more shifts into highly configurable software, it’s not surprising to see this category move up. The former category for A4:2017-XML External Entities (XXE) is now part of this risk category.
- A06:2021-Vulnerable and Outdated Components was previously titled using components with known vulnerabilities and is #2 in the top 10 community survey, but also had enough data to make the top 10 via data analysis. This category moved up from #9 in 2017 and is a known issue that we struggle to test and assess risk. It is the only category not to have any Common Vulnerability and Exposures (CVEs) mapped to the included CWEs, so a default exploit and impact weights of 5.0 are factored into their scores.
- A07:2021-Identification and Authentication Failures was previously broken authentication and is sliding down from the second position, and now includes CWEs that are more related to identification failures. This category is still an integral part of the Top 10, but the increased availability of standardized frameworks seems to be helping.
- A08:2021-Software and Data Integrity Failures is a new category for 2021, focusing on making assumptions related to software updates, critical data, and CI/CD pipelines without verifying integrity. One of the highest weighted impacts from Common Vulnerability and Exposures/Common Vulnerability Scoring System (CVE/CVSS) data mapped to the 10 CWEs in this category. A8:2017-Insecure Deserialization is now a part of this larger category.
- A09:2021-Security Logging and Monitoring Failures was previously A10:2017-Insufficient Logging & Monitoring and is added to the top 10 community survey (#3), moving up from #10 previously. This category is expanded to include more types of failures, is challenging to test for, and isn’t well represented in the CVE/CVSS data. However, failures in this category can directly impact visibility, incident alerting, and forensics.
- A10:2021-Server-Side Request Forgery is added from the top 10 community survey (#1). The data shows a relatively low incidence rate with above average testing coverage, along with above-average ratings for Exploit and Impact potential. This category represents the scenario where the security community members are telling us this is important, even though it’s not illustrated in the data at this time.

ISO/IEC 27000
The 27034 standard was developed by the International Organization for Standardization (ISO) and the International Electro-technical Commission (IEC), and it is part of the ISO/IEC 27000 family of standards. These guidelines help businesses include security in the creation and management of software systems. These recommendations apply not just to in-house application development, but also to the secure deployment and administration of third-party solutions in the company.

Web Services Security (WS-Security)
For sharing structured data, web services commonly employ the Simple Object Access Protocol (SOAP) protocol definition. SOAP makes use of the Extensible Markup Language (XML), which is unsafe on its own. Web Services Security (WS-Security, or WSS) is a SOAP extension that allows web services to be secured.

WS-Security describes three main mechanisms, as follows:
- How to sign SOAP messages to ensure integrity (and also nonrepudiation)
- How to encrypt SOAP messages to ensure confidentiality
- How to attach security tokens to ascertain the sender’s identity

Forbidden coding techniques
While it would be impossible to cover every risky coding practice, there are a few techniques and strategies that you should avoid and be aware of, unless absolutely essential, an app should not do the following:
- Request enhanced rights.
- Allow access to parts of its app package with fewer restrictions.
- Connect to the internet in ways that aren’t essential.
- Keep an eye out for connections on non-essential network ports.
- Inadvertently listen for connections on public network interfaces.
- Unless the user directs otherwise, read or write files in publicly readable directories.

In addition, the following code-hardening approaches must be used:
- Add code to prevent integer overflows by validating inputs.
- To avoid buffer overflows, replace all unsafe string function calls with buffer size-aware ones.
- If at all possible, avoid giving data to interpreters. When using interpreters is inevitable, ensure that data is passed to the interpreters in a secure manner.
- Use parameterized application programming interfaces (APIs) to prevent command injection attacks in SQL queries (or manually quote the strings if parameterized APIs are unavailable).
- Use the POSIX system function sparingly.
- Set sensible settings for environment variables (PATH, USER, etc.) and don’t base security choices on them.
- Fix problems that might lead to race situations and erroneous behavior (or worse).

Code quality
Another factor to consider when incorporating security into an application is code quality. Code quality is a phrase that is described in a variety of ways by various sources, but high-quality code includes the following characteristics:
- Well-documented: The code is self-explanatory, with comments outlining the code’s purpose and functions.
- Maintainable: Because the code isn’t overly complicated, anyone working with it doesn’t need to grasp the entire context to make changes.
- Effectiveness: The code does not waste resources in order to complete the task.
- Simplicity: The code is simple to read and comprehend.
- Formatting has been refactored to be consistent and adhere to the language’s coding norms.
- Well-tested: Critical issues are detected and fixed during testing to guarantee that the product performs as intended.
- Longevity: The code will be used for a long time.
When the code is of high quality, it is considerably less likely to be hacked and is more likely to withstand assaults.

Code analyzers
Both automated tools and manual code review are used in code testing and analysis. The following sections look at some of the types of testing that code analysis could include, as shown below:



Figure: Code Analyser

Fuzzing
In order to evaluate how an application behaves, fuzz testing entails inserting erroneous or unexpected input (also known as faults) into it. It’s normally done with the help of a software program that automates the procedure. Environment variables, keyboard and mouse events, and API call sequences are all examples of inputs. The logic of the fuzzing process is shown below :



Figure: Fuzzing Process

To determine the susceptibility to a fault injection attack, two of the following methods of fuzzing can be used:
- Mutation fuzzing: This type entails altering the current input values (blindly).
- Generation-based fuzzing: This method entails creating inputs from scratch based on a specification or format.
- Use fuzz testing to help uncover flaws and avoid fault injection attacks.
- Follow proper coding and project management procedures.
- Install firewalls at the application level.

Fuzzers are software tools that use a method called fuzzing to detect and exploit flaws in online applications. They work by inserting semi-random data into the program stack and then looking for problems. They are simple to use, but one of their drawbacks is that they are more likely to identify basic faults than the more sophisticated ones. JBroFuzz and WSFuzzer are two specialized tools recommended by OWASP, an organization dedicated to enhancing software security. WSFuzzer is primarily interested in HTTP-based SOAP services. A fuzzer could be used during the creation of a web application that will handle sensitive data, for example. The fuzzer will assist you in determining whether the program is processing error exceptions correctly.
Let’s imagine you have a web application that is still being tested, and you find that if you input your credentials incorrectly on the login page, the software crashes and you are greeted with a command prompt. If you wanted to explore the problem, you could use an online fuzzer to simulate the login screen. Figure 19.7 depicts a fuzzer named Peach with a mutator named StringMutator that changes the input on a regular basis. Some input to the tool can even cause a crash.

Peach confirms the error by duplicating it. It sends extra information to a log, which you may analyze to figure out which string value caused the crash, as shown below:


Figure: Peach Fuzzer Output

Microsoft SDL File/Regex Fuzzer consists of two components. The first is File Fuzzer, which creates random content in files, and the second is Regex Fuzzer, which tests regular expression-based routines. Although these tools are no longer accessible, Microsoft now offers a cloud-based fuzzing service.

Microsoft’s Security Risk Detection (MSRD) solution employs artificial intelligence to automate the reasoning process used by security professionals to uncover problems, as well as cloud-based scalability. The user is guided through the fuzzing process by Regex Fuzzer.

Static
Static testing is the process of evaluating or testing software while it is not in use. Code review is the most prevalent method of static analysis. The systematic analysis of the code for security and functional issues is known as code review. It can take many different forms, ranging from informal peer review to formal code review. There are two types of reviews as presented below.
- Formal evaluation: This is a very detailed, line-by-line inspection that is frequently done by numerous people across several phases. This is the most time-consuming sort of code review, but it is also the most effective in terms of detecting bugs.
- Lightweight review: Unlike a formal review, this style of code review is significantly more cursory. It is typically carried out as part of the development process. It can manifest itself in the following ways:
- Pair programming: Two coders work side by side, constantly verifying each other’s work.
- Email: When time allows, the code is emailed to colleagues for them to evaluate.
- Over-the-shoulder: Co-workers look over the code while the author explains why he or she did what they did.
- Tool-assisted: The most efficient technique is to use automated testing tools.

While code review is most commonly performed on internal programs, it may also be necessary for other situations. Assume you’re working with a third party to design a web application that will handle credit cards. Given the sensitive nature of the program, it’s not uncommon for you to seek a code review to assess the product’s security. Several tools should be utilized to test an application in many circumstances.

For example, an online banking application that has had its source code updated should be subjected to both penetration testing and a code review of the important models to guarantee that no flaws exist.

Dynamic
Dynamic testing is the process of testing software while it is in use. This testing can be done manually or with the help of automated testing software.

Dynamic testing can be approached in the following two ways:
- For websites and applications, synthetic transaction monitoring, a sort of proactive monitoring, is frequently favored. It gives visibility into the application’s availability and performance, alerting users to any possible issues before they notice a change in the app’s behavior. External agents are used to perform scripted transactions on an application.

Synthetic transactions, for example, are used by Microsoft’s System Centre Operations Manager to monitor databases, webpages, and TCP port utilization.
- Real user monitoring (RUM) is a sort of passive monitoring that records and analyses every transaction made by a user of an application or website. Unlike synthetic monitoring, which tries to glean performance insights by testing simulated interactions on a regular basis, RUM eliminates the guesswork by showing you exactly how your users interact with the app.

Misuse case testing
Misuse case testing, often known as negative testing, examines a program to ensure that it can manage unexpected behavior or invalid input. This testing is done to guarantee that an application does not crash and to improve the quality of the program by discovering its flaws. When organizations conduct misuse case testing, they should expect to identify issues.

Testing for the following circumstances should be included in misuse testing:
- All required fields must be filled out.
- Fields that have a certain data type can only take data of that type.
- Fields with a character limit only accept data that falls within that limit; fields with a set data range only take data that falls within that range.
- Only valid data is accepted in fields.

Test coverage analysis
Test cases that are written against the application requirements specifications are used in test coverage analysis. To write the test cases, participants in this study do not need to see the code. Test groups relate to a fraction of the test cases that were run, passed, failed, and so on, after a document describing all of the test cases has been produced.

Test coverage analysis is frequently done as part of unit testing by the application developer. Overall test coverage analysis is used by quality assurance organizations to show test metrics and coverage according to the test plan. To boost coverage, test coverage analysis generates more test cases. It aids developers in locating portions of an application that are not subjected to a set of test cases. It aids in the calculation of a quantitative measure of code coverage, which indirectly gauges the application or product’s quality. One drawback of code coverage assessment is that it only tests what the code does not cover or what has not been developed. Furthermore, rather than looking at structures or functions that do not yet exist, this approach looks at those that do.

Interface testing
Interface testing determines whether the systems and components of an application communicate data and control to one another correctly. It checks to see if module interactions are performing properly and if errors are being handled correctly. Client interfaces, server interfaces, remote interfaces, graphical user interfaces (GUIs), APIs, external and internal interfaces, and physical interfaces should all be tested. GUI testing is using test cases to test a product’s graphical user interface to ensure that it fits its specifications. API testing entails testing APIs separately and as part of the end-to-end transactions performed during integration testing to see if they deliver the expected results.

Agile
Many of the processes that have been examined thus far are based on strict adherence to process-oriented paradigms. In many cases, the emphasis is on following procedural processes rather than reacting rapidly to changes and enhancing efficiency. Continuous feedback and cross-functional teamwork are increasingly important under the agile methodology. Agile aims to be agile enough to respond to unexpected situations throughout development. Less time is spent on upfront analysis, and greater emphasis is given to learning from the process and implementing real-time lessons acquired.

Throughout the process, there is also increased interaction with the customer for the agile model, as shown below:



Figure: Agile model

DevOps
Traditionally, the software development process’ three main actors—development (Dev), quality assurance (QA), and operations (Ops)—performed their functions separately or in silos.

The figure below shows that the work would flow in a linear pattern from development through quality assurance to operations:


Figure: Traditional development

Due to a general lack of collaboration among the units, this frequently resulted in delays, finger-pointing, and many iterations through the linear cycle. Shorter development cycles, increased deployment frequency, and more reliable releases are all goals of DevOps, which are closely aligned with business goals.

The figure below shows the DevOps paradigm, which encourages the three groups to collaborate throughout the development process:



Figure: DevOps

Versioning
Versioning is an organizational concept that assigns a numbered system to software versions to help identify where they belong in the version history. Versioning ensures that developers are working with the most recent versions and that users are also using the most recent versions. There are several ways that can be applied. Changes in version numbers may introduce new features or fix bugs. A hierarchy is used to denote major and minor changes in a sequence-based versioning numbering system.

The figure below shows an example of this type of numbering; a major revision could be denoted by a change from 3.0 to 4.0, whereas minor version modifications are denoted by 4.6 to 4.7, and patches are denoted by 4.7.5 to 4.7.6:


Figure: Components of versioning

Other systems may be based on alphanumeric codes or the date of release.

Secure coding standards
Secure coding standards are methods that help limit an application’s attack surface when followed throughout the software development life cycle. For common programming languages like C, C++, Java, and Perl, standards are produced through a community effort.

Documentation
Documentation is important during the development process to ensure optimal functionality and security. Many processes should be documented, resulting in multiple documents. The sections that follow look at some of these procedures and the documents that come from them.

Security requirements traceability matrix
A security requirements traceability matrix (SRTM) lists the security requirements that must be met by a new asset. In a grid, such as an Excel spreadsheet, the matrix maps the requirements to security controls and verification processes. The columns document the requirement identification number, description of the requirement, and source of the requirement, as well as the test goal and test verification technique for each row in the grid. It enables security professionals and developers to guarantee that all requirements are defined, implemented in the final design, and thoroughly tested. An SRTM would aid in determining whether the security requirements set at project inception are carried through to implementation with a sufficient level of certainty.

Consider the following scenario. Assume a group of security engineers design a corporate network using regulatory and business guidelines. Based on their efforts and a thorough examination of the entire set of functional and performance criteria in the network design, the engineers create an SRTM. In this instance, the aim of an SRTM is to allow certifiers to verify that the network complies with applicable security criteria.

Requirements definition
A collection of functional and security requirements that must be met during the software development process is referred to as a requirements definition. It might be in a variety of formats. Contract style requirement lists, which are exactly what they sound like – lists of criteria, are one conventional approach of documenting needs. Another approach is to express these requirements using use cases, which are a set of scenarios that describe how the system should interact with a human user or another system in order to accomplish a given business goal.

System design document
The software is described in the system design document (SDD), which is frequently accompanied by an architectural diagram. It includes the following details:
- Data design: This sort of design explains the features and relationships between data objects that led to the selection of data structures.
- Architecture design: Data flow diagrams and transformation mapping are used to describe distinct boundaries between incoming and exiting data in this type of architecture. It incorporates information flow features into the program’s structure. All interfaces, including internal and external program interfaces, as well as the design of the human interaction, are classified as interface design.
- Procedural design: This form of design uses graphical, tabular, and textual notations to represent procedural detail and organized programming concepts. It serves as a roadmap for implementation and serves as the foundation for all subsequent software engineering work.

Testing plans
A test plan is a document that outlines the test’s scope (what it will test) as well as the precise actions that will take place throughout it.

Test plans come in a variety of shapes and sizes, which are as follows:
- Master test plan: For a project/product, this is a single high-level test plan that unifies all other test plans.
- Testing level-specific test plan defines a test process at a lower level of testing, as follows:
- Plan for unit testing
- Pan for integration testing
- System test strategy
- Acceptance test strategy
- Testing type-specific test plan: This is a plan for a specific issue, such as performance or security testing. Create a test template to guarantee that all essential actions are completed and all relevant testing data is captured.

Validation and acceptance testing
Validation testing guarantees that a system fits the client’s requirements, whereas acceptance testing ensures that the system is accepted by end-users. The implementation of a system that fits the client’s criteria but is not accepted by the end-users will be considerably impeded. If a system fails to meet a client’s needs, the client is likely to refuse to utilize it until the criteria are met. Before a system is formally given to a client, it should undergo validation testing.

Acceptance testing should be carried out with a subset of users after validation testing has been finished. Validation and acceptance testing should be performed on more than simply systems. As a security professional, you must ensure that validation and acceptability testing are performed on any security controls deployed in your organization. There could be consequences for your business if you adopt a new security control that does not adequately guard against a recognized security issue. Employee morale will suffer if you deploy a security control that causes problems, delays, or any other user acceptance concerns. It’s crucial to strike a balance between the two.

Unit testing
Software is usually created in bits, or as code modules, which are then put together to create the final output. In a method known as unit testing, each module should be tested separately. It’s vital to have development employees conduct this testing, but using engineers who aren’t part of the team that built the code can ensure that the process is fair. This is an excellent illustration of the notion of job separation.

Unit testing should include the following characteristics:
- The test results are included in the specifications.
- Out-of-range values and out-of-bounds circumstances should be checked during testing.
- Test output results that are correct should be generated and known ahead of time.
- Using live or actual field data in unit testing techniques is not encouraged.

Additional testing is recommended, including the following:
- Integration testing: This sort of testing evaluates how the modules interact and determines whether the functional and security requirements have been met.
The advantages to integration testing include the following:
- Provides a systematic technique for assembling a system while uncovering errors.
- Confirms assumptions that were made during unit testing.
- Begins as soon as the relevant modules are available.
- Verifies whether the software modules work in unity.

The disadvantages include the following:
- Locating faults is difficult.
- Some interface links to be tested could be missed.
- Starts only after all the modules are designed.
- High-risk critical modules are not isolated and tested on priority.

- User acceptance testing: This sort of testing ensures that the software’s functionality is satisfactory to the customer (internal or external).

The advantages to user acceptance testing include the following:
- Satisfaction of the client is increased.
- Criteria for quality are set early.
- Improved communication between team and customer.
The only disadvantage is that this testing adds cost to the process.
- Regression testing is performed after modifications to the code have been done to check that the changes have not compromised functionality or security. Some of the benefits are as follows:
- Improved change integration
- Higher product quality
- Detection of unfavorable consequences
The only drawback is the higher price, but it is well worth it.
- Peer review: Developers analyze each other’s code for security vulnerabilities and code efficiency through peer review testing. It has the benefit of being more thorough than the automated procedures. The drawback is that it takes time.

Adapt solutions
Every day, new security dangers and trends arise. To keep the enterprise safe, organizations and the security professionals who work for them must adapt to new threats and grasp new security trends. An organization’s security goal, on the other hand, rarely changes.

Retail businesses are increasingly being targeted. Hackers breached security and stole sensitive client data, according to one company’s public statement. Unfortunately, it appears that not every major shop was aware of the attack when it occurred, as a new victim appears almost monthly. As a result, banks and other financial institutions were required to provide their customers with new credit/debit cards.

Retailers, their customers, and financial institutions were all impacted by these attacks. What might these businesses have done differently to avoid these attacks?

When these types of attacks occur, perhaps more information should be shared within the retail business and among security professionals. Unless we discover some solutions, incidents like these will become the norm, and this is only one recent example of new challenges to which businesses must react.

The figure below shows a common vulnerability cycle that is taught in many security seminars and explains the order in which the attackers exploit vulnerabilities over time:


Figure: Vulnerability management lifecycle

This vulnerability cycle tends to be followed by trends. A period in which human engagement and social engineering are common will be quickly followed by a period in which network attacks are common. As soon as a business adopts it, the attackers move on to the next phase of the cycle – services and servers. Organizations evolve with time, but so do adversaries. You must endeavor to stay one step ahead of the attackers as a security professional. You can’t relax once you’ve introduced a new security control or solution. Then you must conduct a study, keep an eye on your business, and identify the next threat or trend. One thing is certain – a security professional with genuine talents and a desire to learn and adapt will always have a job. An organization’s understanding of emerging dangers is aided by threat intelligence. The organization will be better positioned to protect against new dangers once they are fully recognized. As a result, security professionals will be better prepared for the hazards to which they are exposed.

Addressing disruptive technologies
Disruptive technologies are those that are so innovative that they transform the way things are done and allow people to use technology in new ways. They are disruptive in the sense that they can alter the way a whole industry works. Self-driving automobiles, for example, will almost probably eliminate the need for chauffeurs. While disruptive technologies are usually innovative and forward-thinking, they are not necessarily safe. Security isn’t often a top priority while rushing to bring a breakthrough technology to market. As a result, many companies allow others to be on the cutting edge of technology.

Note: Some of the disruptive technologies on the horizon will make the four-year upgrade cycle obsolete. Desktop upgrades will be done on a yearly basis.

Phishing assaults are expected to increase by 25% in 2022, prompting security professionals to concentrate their efforts in the following areas:
- Ensuring perimeter security.
- Encryption in transit and at rest.
- Bring-Your-Own-Device (BYOD) initiatives will promote mobile device management (MDM) solutions.
- Security-related usability difficulties will become less of an issue.
- There will be more cloud movement and adoption.
- Machine learning and artificial intelligence will be increasingly used to find new clients and customers.
- 5G wireless is expected to be at least 40 times faster than 4G and have at least four times the coverage.

Address security trends
By their very nature, trends are transient, and security trends are no exception. Some security visionaries predict the following in our future as we approach the 2020 decade:
Returning to the zero-trust paradigm: In the face of increasingly sophisticated threats, businesses will adopt a strongly defensive stance. Every privilege shall be granted to a user only when it is absolutely necessary. In the struggle to safeguard the Internet of Things (IoT), deception technologies will become more prevalent. This method floods the network, effectively preventing fraudsters from gaining access to a genuine set of user IDs. Deception technology warns IT when one of these forged credentials is hacked and utilized.

In order to manage identities, behavioral analytics and artificial intelligence will be used as follows:
- The system will learn user habits and will be able to detect unusual behavior quickly. Robo hunters will be utilized as automated threat hunters, learning from their findings and taking appropriate action (for example, by isolating a bad packet or compromised device).
- Blockchain will become more widely used: Blockchain is a distributed network of computers that allows a digital log of transactions to be established and shared among participants. The blockchain ledger can identify and pinpoint dubious internet activities. This unchangeable ledger can also be used in court to show that data was retrieved or copied by an unauthorized person.

Asset management (Inventory control)
Asset management and inventory control are crucial throughout the technology life cycle to ensure that assets are not stolen or lost, and that data on assets is not hacked. Inventory control and asset management are two topics that are intertwined. Asset management is keeping track of an organization’s devices, while inventory control entails keeping track of and containing inventories. Asset management should be implemented by all organizations, while inventory control is not required by all organizations.

Device-tracking technologies
Device-tracking technologies enable enterprises to know the position of a device and, in many cases, retrieve the device. If the device cannot be retrieved, it may be necessary to erase the device to ensure that unauthorized users cannot access the device’s data. You should emphasize to your organization as a security professional the importance of implementing device-tracking technologies and remote wiping capabilities.

Geolocation/GPS location
Geolocation, or the location of a device using the Global Positioning System (GPS), is one of the device-tracking technologies. If the necessary feature on the device is enabled, location and time information about an item can be tracked using this technology. The geolocation or GPS location capability on most mobile devices can be improved by connecting to Wi-Fi networks. A security professional must ensure that the company’s mobile device security policy incorporates the use of GPS location functions as a requirement. Additionally, suitable credentials must be set up to allow workers to utilize the vendor’s online device locating service. Finally, if the mobile devices hold confidential or private information, remote locking and wiping options should be properly examined.

Object tracking and containment technologies
Object tracking and containment systems are largely focused on keeping inventory within a designated region or location. Organizations can use object tracking systems to find out where their inventory is. When inventory leaves the perimeter of a predetermined place or area, containment technologies notify employees within the business.

Object tracking and confinement systems are often utilized only for inventory assets worth more than a specific amount. For high-priced electrical gadgets and jewelry, for example, most retail stores use object containment methods. However, some firms, particularly in big warehouse environments, use these systems for all inventories. Geotagging/geo-fencing and radio frequency identification (RFID) are two technologies utilized in this area.

Geotagging/Geo-fencing
Geotagging is the process of adding a GPS position to a video, photo, or other digital media. This function has recently gotten negative press since the attackers can use it to locate sensitive information, such as a person’s home address. Geotagging, on the other hand, can be utilized by businesses to produce location-based news and media feeds. In the retail industry, it can assist customers in locating a store where a specific item is available.

Geofencing is a method of defining geographic boundaries using GPS. A geofence is a virtual barrier that can trigger alerts when inventory enters or escapes. Geofencing is employed in a variety of industries, including retail, transportation, human resources, and law enforcement.

RFID
To keep track of inventory, RFID chips and readers are used. The chips are placed on individual inventory items or pallets. To communicate with the chips, RFID readers are installed around the area. As part of the RFID communication, identification and location data are acquired. Organizations can tailor the information stored on an RFID chip to meet their specific requirements. Active reader/passive tag (ARPT) and active reader/active tag (ARAT) RFID systems can be used. The active reader in an ARPT system sends out signals and gets responses from passive tags. Active tags are woken up in an ARAT system by signals from the active reader. If RFID chips are within a particular range of RFID readers, they can be read-only.

Conclusion
This guide covered systems and software development lifecycle, including requirements, acquisition, testing and evaluation, commissioning/decommissioning, operational activities, asset disposal, and asset/object reuse.

We also discussed Adapt solutions, emerging threats, disruptive technologies, and security trends.

Asset management, including inventory control and associated concepts were also discussed.