Information Technology systems are always more central to the operation of both business and government. But as the reliance on these systems grows, so do the consequences of outages and security incidents. Therefore, it is essential for organisations to understand the risks a new system introduces to their network and how to mitigate them to the greatest extent possible.
Through the Certification and Application process, an IT system can be declared safe and authorised to operate within an organisation’s system. This formal declaration is known as Authorization to Operate (ATO), and it’s usually signed after a Certification Agent confirms that the product has met all the requirements. Let’s learn more about ATO.
What Is ATO?
ATO (authorization to operate), sometimes called Authority to Operate, is the approval for an information system or software product to be used in an existing system or organisation. For instance, before employees install a software program on a network, the program may require an ATO. The authorisation certifies that the product’s benefits outweigh its operational risks, so it can work with existing systems.
The federal government often uses ATO for Information Technology to manage network risks by assessing security controls for new and existing systems. Every information system operated on behalf of or by the federal government is required to meet the FISMA (Federal Information Security Modernization Act) standards, which include the assessment and monitoring of system security and risksand an ATO certified by an Authorizing Official (AO) who then takes responsibility for the security and risks involved with operating that system.
An Authorizing Official, who can be Chief Information Security Officer (CISO), Chief Information Officer (CIO), Chief Technology Officer (CTO), or Deputy Secretary, makes the decision to authorise the operation of a system on behalf of a federal agency and has to explicitly accept the residual risk of the system to the agency operations based on the implementation of a constituted set of security controls. However, to convince the AO to sign an ATO, the security posture of the information system must be thoroughly documented.
The FISMA requires that federal government agencies have systems in place to assess and monitor the security risks of products. These may be implemented by every department independently, like the Department of Defense (DoD) through the Defense Information System Agency, or by inter-departmental agency bodies such as the Federal Risk and Authorization Management Program (FedRAMP), which certifies cloud-based products and services for many government departments. The certifying body for each agency varies; therefore, you should identify an agency that would be suitable for your products.
Why Do Organisations Use ATOs?
While organisations may use ATOs for any reason, they primarily use them for security or operational integrity concerns. For instance, if you develop software designed to be used within an organisation’s Information Technology system, it could pose security concerns for the organisation and its systems.
Therefore, before allowing your product to connect to its network, the organisation needs to ascertain that there’re no flaws in your product that could compromise its network data. The organisation must also determine if it works correctly and won’t cause issues with the existing apps or cause unnecessary technical support problems.
ATO Application Process
If an organisation requires that you obtain an ATO before using your product, you must contact the certifying body within that organisation for testing. The ATO application process varies depending on the IT system requesting authorisation and the organisation or government systems it’s requesting access to. During the ATO process, systems or products undergo extensive testing and hardening against the organisation’s security and privacy standards.
The steps in the ATO process generally align with the Risk Management Framework (RMF). The RMF describes integrating Information Security Risk Management (ISRM) activities into the system development life cycle. This process should be followed to authorise, secure, and manage information systems.
The six steps process cycle, commonly associated with the National Institute of Standards and Technology (NIST), design and engineer a data security process for a new information system and recommend best practices federal agencies should follow when enabling a new system. These processes include:
1. Categorise
The categorisation is based on the system’s potential impact analysis. It is performed to determine the system’s security requirements, types of information included within the authorisation boundary, and potential adverse impact due to security compromise. Agencies should categorise their information systems as high-impact, moderate-impact, and low-impact, according to the Federal Information Processing Standard Publication (FIPS PUB) 199, Standards for Security Categorization of Federal Information and Information Systems, for the security objectives of confidentiality, integrity, and availability.
2. Select
After categorising the system, agencies are required to select appropriate security controls. Controls are the management, technical, and operational safeguards employed within an organisational information system to protect the system and its information’s confidentiality, integrity, and availability.
3. Implement
The defined security controls in the System Security Plan (SSP) are implemented by considering NIST SP 800-53 Security and Privacy Controls for FISO (Federal Information Systems and Organizations) and the organisationally defined parameters.
4. Assess
After the implementation of the security controls, an assessment follows to determine their effectiveness in meeting the security requirements of the system. A security assessor extensively assesses operational, management, and technical security controls and prepares a Security Assessment Report (SAR). The assessors also control enhancements employed within or inherited by an information system.
5. Authorise
The risks identified during the security control assessment are evaluated, and a decision is made to authorise the system to operate, deny its operation, or remediate the deficiencies.
6. Monitor
After the ATO is granted, continuous monitoring is performed on the identified security controls, and any changes to the system are documented and reviewed.
Due to the volume of systems requesting authorisation and the extensive process, ATO processes, such as the DOD ATO process, can take several years. The cost is also highly variable depending on the AO assigned to the system. During this period, documentation and scans must be continually updated to remain current upon AO review.
As an intermediate step, the government or organisation may issue an Interim Authority to Test (IATT), which grants temporary authorisation to test a system without live data for a specific period under certain conditions or constraints.
Authorisation Package
To satisfy an agency’s requirements for a completed ATO, the ISSO or ISSO team must complete a set of documents that fully describe the security controls in place to protect the information system. This set of documents is referred to as an authorisation package.
An authorisation package contains the essential information that an AO uses to determine whether to authorise or deny the operation of an information system. An authorisation package includes a System Security Plan, Disaster Recovery Plan, Security Assessment Report, Risk Assessment Report, Incident Response Plan, Security Control Assessment, Privacy Impact Assessment, and Plans of Action and Milestones.
Types of ATO Status
When you apply for an ATO, you can be given one of three statuses. If your system or product is issued an ATO, it can be used within the organisation. A denial of authorisation to operate means the system may not be used within the organisation. Finally, you may be issued an interim Authorization to Operate, which means you can operate for a short period, between 90 to 180 days, or under limited conditions until your system is denied or approved.
ATO Best Practices
1. Completion of Certification and Accreditation Process
ATO depends on the successful completion of the C&A process. This process ensures the IT system complies with an organisation’s security controls. As a software provider, you should initiate and plan the process or outsource it to the systems integrator or Managed Service Provider (MSP) to complete the C&A process properly. Tackling the C&A process without proper knowledge or resources can lead to costly delays and denial of accreditation. Also, the Certifying Authority needs to understand the C&A process and collaborate with the Designated Accrediting Authority (DAA) or AO to facilitate the ATO process effectively.
2. Use a Robust DevSecOps Process
As a software provider, getting the all-important ATO for your software faster requires a stringent DevSecOps (Development Security and Operations) process that combines people, processes, and technology. Therefore, you should train your personnel, develop a security plan, test and remediate vulnerabilities during the software development life cycle, and continuously monitor production for emerging security threats.
3. Time Management
The ATO process can be a long process taking several years. Therefore, the CA should start the C&A process early and do a follow-up in order to receive an ATO on time. The CAs can also reduce the assessment time in the ATO process by accessing the audit trails generated throughout the Software Development Life Cycle (SDLC). This assures them that the system adheres to NIST and other security requirements hence shortening the release cycles of IT systems in an organisation.
Maintaining ATO
ATOs are valid for a specific period of time, mostly three years, based on the assumption that the system’s security posture won’t significantly change during that period. However, this assumption may be unrealistic because agile software development practices expedite and embrace change. As changes are inevitably made, ATOs become insufficient, resulting in a need to reassess and reauthorise the system.
Nevertheless, authorisation is not the end line for an IT system. Continuous monitoring is key to maintaining confidence in any system and its security controls once the risks are assessed and the system authorised.
Conclusion on Authorization to Operate
An ATO can be a significant barrier to entry into the government market. The ATO application process is a long, complex beast that often proves fatal for startups targeting government customers. However, getting through it is vital for companies who want to provide products and services to federal agencies. Also, by limiting the information systems available to the government to only products from companies that can afford ATO, the government and private organisations misses out on innovative solutions from startups.
However, besides ATO’s imperfect process, it provides the best systematic way for organisations and government agencies to manage cybersecurity risks within their information systems.
Featured Image by rawpixel.com on Freepik.
