.png)
The string of to-do’s when developing, acquiring, reviewing, and finally accepting a new system can be confusing.
Here are a few pitfalls to avoid when doing so that will drive the success of your business.
Development
When developing internally, through a third-party, or through any other acquisition of systems, you need a defined process implemented and managed right away. If they are not, it could potentially lead to the major security vulnerabilities. By specifying development and acquisition security controls, you avoid the unnecessary risk when introducing the system to your organization.
While in the development process, developers should be required to provide a description of the functional properties that are contained within new systems or applications to meet the Security Program control requirements for your organization. They should also provide design and implementation information for the selected, in-scope security controls. This should include any security-relevant external system interfaces, high-level design, as well as source code or hardware schematics at an appropriate level of detail. Lastly, developers should identify the functions, ports, protocols, and services intended or required for use by your organization once a new system or application is ready for testing.
Make sure it is required to only give access to program source code to only authorized users. Test data should be selected carefully, protected, and controlled in all non- production environments. The use of operational databases or data components that contain protected information (e.g., PII, PHI, CUI, FCI, etc.) for non-production development or testing purposes should be discouraged and avoided if possible.
Acquisition
Your organization should ensure that system acquisition contracts include the functional security control requirements for security and data privacy. These contracts should also include references to strength of mechanism requirements. Security and privacy control assurance requirements that address the security and privacy of documentation and information should be defined as well.
Acquisition contracts should contain a description of the system development environment, along with the environment in which that system is intended to operate once it is implemented within your organization. The allocation of responsibility or identification of parties responsible for the security, privacy, and supply chain risk management controls should be defined. Acceptance criteria for your organization should be defined in acquisition contracts, in accordance with the Security Program control requirements that have been adopted.
Review
New systems or applications should be reviewed prior to being accepted to make sure that organization level security and functionality requirements are in place. Make sure that systems and applications are formally authorized for use before they are implemented in the production environment. This is important because organizations cannot possibly protect systems, applications, data, or the overall environment unless the assets operating within the environment are known and understood.
Authorization
An authorization process for new information systems, applications, as well as the facilities where they operate should be defined and implemented. An executive or senior-level manager should be assigned as the authorizing official for information systems. The assigned person should also be responsible for the security controls required for the systems. It is also important that the authorizing official should authorize systems prior to commencing production operations.
When to Update?
System authorizations should be updated at least every three years. If your organization manages a system related to a federal agency, you likely already understand that system authorizations can be a long process. The good news is that there are multiple ways to shorten this process and the accompanying requirements. This is another great example of how implementing an effective Security Program once, then moving into continuous monitoring will drive your organization to success.
If your organization does not support or manage a federal system, authorizing systems is still appropriate. This process helps to ensure there is a continuous understanding of the systems your organization is using to support business operations. The main point of this blog demonstrates a need to know, and document, as much information as possible about your operating environment.
For more information about these pitfalls, and 99 more, my book will help: 100 Security Program Pitfalls and Prescriptions to Avoid Them (available on Amazon here). Or register for a demo of the ASCENT Security and Compliance Portal and get a free synopsis of the 100 Security Program Pitfalls eBook today.
Dowload the ASCENT Documentation Checklist for ASCENT CSP.
