Certification and Accreditation (C&A) refer to a federally permitted standard procedure to make sure that Information technology systems meet security prerequisites and uphold the accredited security status all through the system life span (Harris, 2002). Because certification and accreditation is a requirement for all information technology systems, frequently it is considered as just an essential step in an attempt to maintain an IT system, and no longer taken once the information technology system implementation is complete (Ross & Swanson, 2003). However, certification and accreditation, if considered in its basic function, can be a valuable mechanism for managing the security of information technology systems all through their life span. Much of the procedure of official certification and accreditation could simply be utilized in the financial sector to better appreciate and control the security status of all widely used IT systems.
To comprehend certification and accreditation, it is vital to differentiate between the two terms. Certification refers to the procedural assessment of the security system and its conformity to be accredited (Feringa, 2002). Certifiers, typically autonomous third parties, check an information technology system for conformity with a documented set of security prerequisites. On the other hand, accreditation refers to the official approval of the competence of the information technology system’s general security by the organization (Casar, 2001).
Frequently, important components of the security system are ignored, or security procedures are documented but ignored. The certification and accreditation procedure compels the documentation of security settings, guidelines, and processes, and confirms their proper execution. The purpose of this paper is that of examining the certification and accreditation procedure, the regulation that assists describe the security needs, and the answerable stakeholders and their functions, in providing an indispensable understanding of certification and accreditation.
Certification and accreditation
Both the Department of Defense Information Technology Security Certification and Accreditation Process (DISTCAP) and National Security Telecommunications and Information System Security Instruction (NSTISSI) describe the certification and accreditation procedure by use of a three-step method: description, authentication, and justification. Each policy material defines the different operations carried out in each step. For instance, the description is aimed at understanding the task situation, and design to determine the security needs and degree of effort required to attain certification (Swanson, 1998). Unluckily, the definition of such a step lacks the aspects of how the needs are established. Therefore, rather than utilizing the three-step approach, this paper will describe the steps essential to attain a certification position.
Certification and accreditation tasks
- The capacity of the information technology structure being accredited is identified.
- A System Security Authorization Agreement (SSAA) manuscript is developed including all required data regarding the system.
- A certifier performs System Test and Evaluation (ST&E), and reports on the appropriate findings.
- Recommendations are drafted by the certifier to the Designated Approving Authority (DAA).
Several such tasks can be carried out in a dissimilar sequence, and further tasks can be included or eliminated based on the technical specifications of the information technology system. However, the tasks presented in this paper represent the fundamental list of steps essential to attain a certification position. In the following section, each task will be defined to demonstrate the efficiency of the certification and accreditation procedure (Ross & Swanson, 2003).
The capacity of the system
Once the list of tasks has been developed, the major stakeholders meet to determine the scope of the certification and accreditation process. In case a key fraction of the system is not controlled by Designated Approving Authority, a further Designated Approving Authority would be essential, and the ultimate certification would be established through the endorsement of the two authorities (Harris, 2002).
Establishment of the SSAA
The creation of the System Security Authorization Agreement (SSAA) is an action that can start at any time throughout the certification and accreditation process. Preferably, the System Security Authorization Agreement would begin to be created at the early stages of the system, because some of the security concerns can influence the design of the information technology platform. The NIACAP recommends having three stages of the creation of systems, and documents processes linked to each of the three basic tasks during each stage. Such a three-stage method is the perfect situation but is optional (Harris, 2002). Indeed, the System Security Authorization Agreement can be established at any time during the certification and accreditation procedure, but evidently, the earlier the System Security Authorization Agreement is developed, the more the system gains from the SSAA (Ross & Swanson, 2003). If the System Security Authorization Agreement is started too late during the project, some adjustments to the design may be required to meet the technical specifications of the System Security Authorization Agreement.
It is important to maintain the System Security Authorization Agreement updated since adjustments occur in the system even after it has been certified so that the System Security Authorization Agreement remains an absolute security scenario of the information technology system (Swanson, 1998).
System test and evaluation (ST&E)
Once the security process has been established, system assessment and evaluation can start. The Certification Team carries out the evaluation process and performs each test in partnership with an individual from the organization (Swanson, 1998). To test that the proper setting of the system has been attained, an Information Technology System Manager that is answerable for that specific aspect will carry out the evaluation, and the certifiers will authenticate the findings.
Results and approval by DAA
Once all the certification and accreditation components have been completed, they are presented to the Designated Approval Authority. They can be presented to the authority for re-evaluation, but in most cases, the approving authority is notified by the Accreditation Group. The approving authority can endorse the certification and accreditation package by giving the system complete Approval to Operate (ATO) or by giving an Interim Authority to Operate (IATO). Denial is very uncommon, as the Designated Approving Authority is regularly updated on the development and challenges of the certification and accreditation process (Ross & Swanson, 2003). Thus, the Accreditation Group and program coordinators are well aware of the perspective of the approving authority and can carry out necessary actions to the system to reduce the risk of denial. In case the system is given a certification, the certification and accreditation remain legitimate for the next 36 months.
Carrying out the official procedure of certification and accreditation may appear tiresome, but the outcome is rewarding. It would be an uncommon scenario that a System Test and Evaluation process has been carried out without detecting faults in the design of compulsory system components. Authenticating such components renders the certification and accreditation process important.
Casar, T. (2001). Federal information processing standards. Information Systems, 14(1), 19-22.
Feringa, A. (2002). Risk management guidelines for information technology systems. Information Systems, 15(1), 23-26.
Harris, S. (2002). All in one CISSP certification exam guide. Columbus, Ohio: McGraw Hill.
Ross, R. & Swanson, M. (2003). Guidelines for the security certification and accreditation of federal information technology systems. Information Systems, 10(1), 20-27.
Swanson, M. (1998). Guide for developing security plans for information systems. Information Systems, 34(1), 37-56.