CHAPTER 4:
THE AUTHORIZATION PROCESS – ESTABLISHING A FOUNDATION
Typically in most global organizations, security is viewed at best as a necessary evil and more commonly as a necessary friction. This derives from security’s primary focus on attempting to constrain behavior to prevent negative events. Although well-intentioned, the inevitable result is that security practitioners are not viewed as enablers of innovation, but people preventing the business from doing what it needs to do.40
Bill Boni, Corporate Vice President, Information Security and Protection, Motorola
In this chapter:
Designing and implementing an effective security program
Information systems security roles and responsibilities
Authorization is only one part of an effective security program
Two years ago, the authors were called in by a major international corporation to help them certify and accredit one of their major information systems as a pre-requisite for sales to the US Government. During initial meetings, we discovered that the system development team had included security considerations in their design. We also discovered that this team was working in a security vacuum – there was no corporate level security program that could assist in coordinating all of the efforts essential to effective authorization. As a result, each authorization was an individual, heroic venture – an individual process limited to a single application. The consequence – the company had to “recreate the wheel” for every new accreditation at great expense and cost to the resources of the company.
How much simpler would it have been for this major international corporation if they had a fully integrated security program, including authorization! An effective security program would have institutionalized the processes necessary to support authorization as part of a consistent, standardized enterprise-level effort. Each authorization would build on those that had gone before and could capitalize on coordinated efforts to gather the required information and conduct the activities necessary for a successful authorization.
This chapter will focus on establishing a foundation for an effective security program, focusing on the elements required for successful execution of certification and accreditation at an organizational level.
The first step is to establish that a security program is not only necessary, but that it supports the overall mission of the organization and ensures a return on investment.
Making the business case – what is the ROSI?
Security is viewed today as a significant component of an organization’s overall infrastructure. We live in a dynamic environment with a variety of assets that need protection, as well as a large and diverse user population. Information and its associated information technology represent some of the most critical organizational assets. It’s not unusual to find that organizations have invested heavily in security technologies, such as firewalls and intrusion detection systems. It is equally common to find that the same organization has not put the same level of investment into establishing and maintaining a security program.
Selling the need for a robust information security program is more important, but may be even more difficult than the complexities of the technical safeguards. Selling an information security program requires an understanding and an ability to address political considerations and business return from the investment in the security program, while the rules are often less clear than those associated with purely technical decisions.
Establishing a security program is serious business, so how should the message be made clear to the senior leaders who make those resource decisions? When it comes to proving the business case for an information security program, it’s much more difficult than simply providing a spreadsheet full of return on security investment (ROSI) and risk numbers. The reality is – it’s just not that simple.
Let’s take a closer look at the essence of ROSI calculations – often defined as the security value received divided by the cost of security over a given time period. So, how does one quantify “value received” when it comes to an information security program? Does a security program save money, make money or does it simply help the organization avoid losing money? If approached from the traditional perspective on ROI, trying to make the business case can feel like an exercise in futility. So, here are a few suggestions on a more productive approach.
Don’t sell FUD – tell them what they have to gain
Many leaders simply don’t understand the positive impact a secure information infrastructure can have on the business. Some may still believe that information security professionals are simply there to set up new users on the network, manage the firewall, and make sure there are no viruses on the network. In just about every organization, each business process – from customer contact to service delivery – can be directly tied back to the organization’s sensitive and fragile computer environment. So, what does the organization have to gain?
A good reputation: An enterprise-level security program can add business value as a competitive differentiator, because there is often a direct link between a company’s reputation and its approach to corporate security. The potential benefits to an organization based on having a good reputation include: differentiation in the marketplace, simply keeping the name of the organization off the front page of the Washington Post, the ability to attract and retain stakeholders, shareholders and customers, as well as the ability to recruit and retain high quality staff. A good reputation can be the most important asset for an organization. An organization’s security reputation will often be of greater concern where security is fundamental to the organization’s product or service; in those cases, compromised security will have a much greater reputational impact on some sectors rather than others.
Freedom to innovate: Perception about the role of the security program has an impact on its ability to effectively contribute to the organization. Too often, the security team is viewed as the group that says “no.” It’s important for the security staff to change the word “no” to the notion of “how.” This is the primary step to becoming a trusted partner of the business innovators. The security program can and should be presented as an enabler for innovation by providing a secure infrastructure that frees the other staff to focus on new ideas. And keep in mind, security is NOT about compliance. So, if the security program has fallen into that mindset, switch the focus to looking at the business initiatives and how the security program can support them on a regular, value added basis.
Risk management: Business is all about risks – every organization faces them. The objective of any security program is to help the organization to do new things or to do the old things more securely and efficiently. It’s impossible to avoid all 4: The Authorization Process – Establishing a Foundation risk. As a result, an effective security program is in touch with the organization’s tolerance for risk and provides an environment that addresses that level of tolerance.
Security consistency: The security program should focus on creating timely and flexible processes that help to facilitate, not delay, essential projects. And these processes should be consistent, so that the organization learns how these work. Having repeatable processes for security can aid in making the argument for a return on security investment and for security value. Aligning these security “templates” to the organization’s business initiatives can actually assist in accelerating the innovation process. Standardized security criteria allow staff to understand how long certain security activities, including authorization, will take and will allow them to include this early in the planning.
So, let’s go back to the corporation introduced at the beginning of this section.
An established security program, including the ability to have a consistent, enterprise-level process for authorization would have provided all of the above-listed rewards for their security investment. Information systems security – the pre-requisite for authorization – would have been integrated into the development process. Costs in terms of dollars and time for obtaining authorization would have been significantly reduced. End result – the time to market for their product would decline, quickly giving them a competitive edge over others in their market space.
Designing an effective information security program
Defining the program
Creating an information security program is like putting up a structure. First, the organization has to decide exactly what it wants from its security program – create its blueprint – and build it accordingly. Too often, organizations jump into security – installing firewalls, intrusion detection systems, and configuring information systems without really defining their end goals. Establishing an information security program and defining the overall information security objectives should be methodical and well-thought out, involving management buy in throughout the process.
The 5000 meter view
In the long term, taking a few steps back at the initiation of a security program will save time and resources by eliminating unnecessary re-work, redundancy, and the need to make dramatic changes mid-stream. This is the foundation of the building, so it’s important to take the following steps in launching your information security program:
Get management support and funding.
Develop a strategic vision with near-, mid- and long-term goals.
Align the information security program with the overall business objectives.
Put a tactical action plan in place.
Communicate, communicate, communicate – both upward and outward.
Getting and keeping resources
Once the broad objectives have been defined, neither the security program nor the organization can move forward without the necessary resources – monetary and human. Of course, getting the budget for the information security program is only the first step. Those involved in developing and implementing the information security program should always design the means to adjust the budget to meet emerging security needs. Funding and other resources are essentially the materials needed to complete the building.
Security governance – establishing the right roles and responsibilities
Information security responsibility begins at the top of the organization and goes all the way down to the individual user. The members of staff represent the walls and roof of the building – they give the program format and maintain it over time. As you build the governance structure for the information security program, it is also important to ensure that the roles and responsibilities assigned incorporate both the organizational and the security program strategy and mission.
The roles and the related responsibilities discussed here focus on those roles defined as part of an overall security program, but there are also several that are specific to the authorization process. When this is the case, it will be identified in the discussion below. While some of the nomenclature may be different, these same roles and responsibilities could apply to the commercial sector.
So, let’s take a look at who is included in the security program governance staff. Nomenclature can be contentious – particularly when positions and staffing are affected. For the purposes of this book, we have decided to use the terminology that has emerged from the DOD and DNI working group on the C&A transformation. So, in many cases you will see position titles joined with “/” – the first title reflects the new terminology proposed as part of the C&A transformation efforts and the second reflects the more historical nomenclature.
Most of the roles and responsibilities described here have long been part of the information systems security program staff. However, new positions and tasks are emerging as a result of the efforts of the C&A transformation and ongoing work in NIST. Those unique to the new and emerging information systems security processes are indicated in blue italics.
Senior leadership
The senior leadership’s responsibility for information security extends beyond the basics of support. They set the tone for the entire program, so it is not enough to utter a few words of blessing for the program. Management must step up to ownership of the security program by becoming a part of the process. The second important role of senior leadership is allocation of the budget for a security program – they decide just how much of the organizational resources can be provided to support the security program.
Senior leadership in the organization bears the final responsibility for information security in both a statutory and a practical sense. In the US federal government, FISMA assigns to senior leadership the responsibility for information security protections commensurate with the risk and the degree of harm that might result from unauthorized access, use, disclosure, disruption, modification, or destruction of an organization’s information and information systems. But this level of security responsibility is not unique to the federal agencies. In short, senior leadership in all types of organizations is responsible for:
oversight of enterprise compliance;
compliance reporting; and
actions to enforce accountability.
Chief information officer (CIO)
The Clinger-Cohen Act of 1996 created the role of agency CIO, helping to bring IT to the forefront of agency decision making. Today, the CIO is one of the primary players in information systems security and the authorization process. NIST SP 800-37 states that the CIO is the federal agency officer responsible for the following:
Appointing the senior agency information security officer.
Ensuring the development of information security policies, procedures, and control techniques.
Initial, refresher, and specialized training for personnel with significant responsibilities for information security.
Advising senior agency officials concerning their security responsibilities.
In coordination with other senior agency officials, reporting annually to the agency head on the effectiveness of the agency information security program, including progress of remedial actions.41
The chief information officer, with the support of the senior agency information security officer (SAISO), works closely with authorizing officials and their designated representatives to ensure that an agency-wide security program is effectively implemented, that the certifications and accreditations required across the agency are accomplished in a timely and cost-effective manner, and that there is centralized reporting of all security-related activities.
The CIO also often executes one additional, critical function. In addition to the above duties, the chief information officer and authorizing officials may be responsible for determining the amount of the organization’s budget that should be allocated to information systems security based on organizational priorities.
Senior agency information security officer (SAISO)/chief information security officer (CISO)
The position of CISO or SAISO in federal agencies, a title often used interchangeably with the chief security officer (CSO)42, is a relatively new position within federal agencies and commercial organizations alike. Senior information assurance officer (SIAO) is the term used specifically within DOD and the IC for this position.
In order to be effective within the organization, this should be a high-level executive position appointed and approved by the senior leadership within the organization. The SAISO carries a heavy burden. He/she must be able to lead and enable the organization in the implementation of security strategy and policies in direct
41 This particular responsibility is limited to US Federal agencies, including DOD, and is not a requirement for the commercial community.
42 The CSO is usually concerned with business continuity, physical and personnel security.
support of the business. Being an effective business process enabler requires the SAISO to also be an innovative problem solver and a leader who can combine common sense security with efficient and productive business processes.
But just being a leader is not enough. The SAISO must also bring subject matter expertise to the position. Credibility within the information security team, coupled with understanding sufficient to craft an integrated information security strategy, depends on the SAISO’s ability to know, value, and effectively articulate the varied security missions. In a few words, the SAISO must successfully fulfill the following (not all security-related) roles:
Relationship manager, who nurtures trust-based connections across the organization.
Leader and manager, who is able to build, motivate and sustain a team of security professionals.
Subject matter expert, who either provides or ensures the availability of technical and procedural expertise.
Risk manager, who identifies, analyzes and communicates the risk posture to the organization and the leadership.
Strategist, who is able to develop and publish a security strategy that aligns correctly with the organization’s mission and goals.
In addition to these high level duties, FISMA also assigns specific responsibilities to the CISO/SAISO that support the primary information systems security duty. According to NIST SP 800-100, Information Security: A Guidebook for Managers, the SAISO is required to:
Lead an office with the mission and resources to assist in ensuring agency compliance with information security requirements.
Periodically assess risk and magnitude of the harm resulting from unauthorized access, use, disclosure, disruption, modification, or destruction of information and information systems that support the operations and assets of the agency.
Develop and maintain risk-based, cost-effective information security policies, procedures, and control techniques to address all applicable requirements throughout the life cycle of each agency information system to ensure compliance with applicable requirements.
Facilitate development of subordinate plans for providing adequate information security for networks, facilities, and systems or groups of information systems.
Ensure that agency personnel, including contractors, receive appropriate information security awareness training.
Train and oversee personnel with significant responsibilities for information security with respect to such responsibilities.
Periodically test and evaluate the effectiveness of information security policies, procedures, and practices.
Establish and maintain a process for planning, implementing, evaluating, and documenting remedial action to address any deficiencies in the information security policies, procedures, and practices of the agency.
Develop and implement procedures for detecting, reporting, and responding to security incidents.
Ensure preparation and maintenance of plans and procedures to provide continuity of operations for information systems that support the operations and assets of the agency.
Support the agency CIO in annual reporting to the agency head on the effectiveness of the agency information security program, including progress of remedial actions.
Risk executive (individual or function)
The risk executive can be a position or a function. Regardless of whether there is a permanent position with an assigned individual or just an identified organizational function, the risk executive supports an enterprise-wide approach for assessing and addressing risk.
The risk executive provides a holistic view of risk that extends beyond the risk associated solely with the operation and use of individual information systems. The risk executive is an individual or group within an organization that helps to ensure that:
Security risk-related considerations for individual information systems, to include the accreditation decisions for those systems, are viewed from an organization-wide perspective with regard to the overall strategic goals and objectives of the organization in carrying out its missions and business functions.
Managing risk from individual information systems is consistent across the organization, reflects organizational risk tolerance, and is considered along with other organizational risks in order to ensure mission or business success.
Authorizing official (AO)/designated accrediting authority (DAA)43
The AO, referred to in the DOD and the IC as the DAA, is usually not a member of the security staff, but rather a representative of the senior leadership of the organization. But the role as AO within the authorization process is an important function of that individual. The AO should be a senior management official or executive with the authority to formally assume responsibility for operating an information system at an acceptable level of risk to an agency. Responsibilities of the AO may include oversight of the budget and business operations of the information system within the agency and approval system security requirements, system security plans, and memorandums of agreement (MOA) and/or memorandums of understanding (MOU).
The AO possesses US government authority and, as such, must be a government employee. In other words, accepting risk on behalf of the government is inherently “governmental” and cannot be passed to a contractor – or to a non-US citizen in the case of National Security Systems.
The AO has the following authorization responsibilities:
43 The term “authorizing official (AO)” is used by NIST and is proposed for use across the Federal government. DOD and the IC – at least at the time of publication – plan to continue to use the term “designated accrediting authority (DAA).” The term DAA will be used in those cases specific to DOD or the IC.
Oversight of the authorization budget and business operations of the system.
Authority to approve system security requirements, system security plans, and memorandums of understanding (MOU) and/or memorandums of agreement (MOA).
Make a risk-based decision to grant, conditionally grant, or deny authority to operate a system.
Appoint, as appropriate, a designated representative to act on the AO’s behalf in coordinating and carrying out the necessary activities required during the authorization process.
The AO/DAA may also have a designated accrediting authority representative or authorizing official designated representative. Due to the level of organizational responsibility and significant demands on time, an AO/DAA may not always be able to participate directly or on a day-to-day basis in the authorization process. The AO’s designated representative can be empowered to act on the AO’s behalf in executing the necessary activities required during the authorization process. This includes the authority to make certain decisions with regard to the planning and resourcing of the authorization activities, the acceptance of the system security plan (SSP), and risk determination processes. It can also involve such mundane activities as making routine decisions, attending meetings, and providing coordination of authorization activities.
It is important to note that there is one activity that the AO representative cannot execute. The AO cannot delegate the security accreditation decision and the signing of the associated accreditation decision letter (i.e. the acceptability of risk to the agency).
Information systems security manager (ISSM)/information assurance manager (IAM)44
The ISSM often serves as the “right-hand man” for the AO and the SAISO. The ISSM provides the focal point for policy guidance on IA matters pertaining to ISs under his/her purview. The ISSM is generally a permanent member of the security staff and, while they often play a role in the authorization process, this may not be their primary function. ISSMs have the following general responsibilities:
Provide security policy and program guidance to subordinate activities.
Maintain overall responsibility for the security program within his/her activity by establishing, managing, and assessing the effectiveness of the program.
Ensure compliance with approved information systems security policies and procedures.
Ensure that compliance monitoring of ISs under his/her purview occurs, and review the results of such monitoring.
Ensure that IA inspections, tests, and reviews are coordinated within his/her activity.
Ensure that all IA management review items are tracked and reported.
Complete job-specific IA training on an annual basis.
Information system security officer (ISSO)/information assurance officer (IAO)
Simply stated, the information system security officer (ISSO) is the individual responsible to the ISSM for ensuring that the appropriate operational IA posture is maintained for a DOD information system or organization. ISSOs shall access only that data, control information, software, hardware, and firmware for which they are
44 The term “information systems security manager (ISSM)” is used by NIST and is proposed for use across the Federal government. DOD and the IC – at least at the time of publication – plan to continue to use the term “information assurance manager (IAM).”
authorized access and have a need-to-know, and assume only those roles and privileges for which they are authorized.
The next two positions – that of the certifying authority (CA) and security controls assessor – are both part of the security controls testing process. While there may be some similarities, there are also some primary differences. The role of the CA, which continues to be used by DOD and the IC, has essentially disappeared from the authorization processes as proposed by NIST and the C&A transformation.
In the DOD especially, the CA acts as an advisor to the DAA on making risk-based accreditation decisions. The CA also has the responsibility for ensuring the security control testing teams are properly qualified and trained. Under the C&A transformation, the role and function of the CA is divided between the emerging risk executive function and the security controls assessor.
So, now that we have confused you thoroughly, let’s talk about each of these roles separately. Hopefully, the discussion that follows will assist you in understanding the current roles and responsibilities as they apply to each of these positions.
Certifying authority (CA)45
The certifying authority (CA) should be an independent entity and not a direct member of the security staff, even though the CA fulfills a critical function in the authorization process. According to the DOD and the IC, the CA has the following responsibilities:
Performing an independent and comprehensive assessment of information system security controls.
Issuing a recommendation to the DAA that includes an assessment of risk.
Recommending the appropriate restrictions and conditions for accreditation.
To preserve the impartial nature of the security certification and testing process, the CA should be in a position independent from the persons directly responsible for the development and the day-to-day operation of the information system. The CA should also be independent of those individuals responsible for correcting the security deficiencies identified during the security certification and testing phase.
The DOD and the IC consider that the objectivity of the CA is an important factor in evaluating the credibility of the validation test results and ensuring that the AO receives the most objective information possible in order to make an informed, risk-based, accreditation decision. Within the DOD, the CA is often assisted by an agent of the certifying authority (ACA), who most frequently conducts the actual controls validation testing.
Security controls assessor
The security controls assessor can be an individual, a group, or an organization responsible for conducting independent and objective security controls testing. This role is similar to the validator in DOD and the IC. The primary difference is that the security controls assessor reports to the risk executive while the validator reports to the CA.
Security controls testing, whether in the federal government, DOD or IC, usually takes the form of a comprehensive and independent assessment of the management, operational, and technical security controls in an information system. The security controls assessor, or the validator in the DOD and IC, has the following responsibilities:
Verify that the controls are implemented correctly, operating as intended, and meeting the security requirements for the system.
Provide recommendations for corrective actions intended to mitigate or eliminate vulnerabilities in the information system.
Conduct an independent assessment of the system security plan (SSP) or equivalent documentation to ensure the plan proposes security controls for the information system that are adequate to meet all applicable security requirements.
Prepare the validation test report and forward the complete report with an accreditation recommendation. In DOD and the IC, the validator will forward this to the appropriate CA. Under the NIST standard, the security controls assessor will provide the results to the risk executive and AO, and in some instances, directly to the system owner.
Common control provider
The common control provider is responsible for the planning, development, implementation, assessment, authorization, and maintenance of common controls (i.e. security controls inherited by or shared between information systems). Common control providers are responsible for:
Documenting common controls in a security plan (or equivalent document prescribed by the organization).
Ensuring that required assessments of common controls are carried out by qualified assessors with an appropriate level of independence defined by the organization.
Documenting assessment findings in a security assessment report.
Producing a plan of action and milestones for all controls having weaknesses or deficiencies.
Security plans, security assessment reports, and plans of action and milestones for common controls (or a summary of such information) must be made available to information system owners whose systems might inherit or share those controls after the information is reviewed and approved by the senior official or executive with oversight responsibility for those controls.
Information owner/information steward
The information owner has statutory or operational authority and responsibility for establishing the controls for the secure generation, collection, processing, dissemination, and disposal of information. The alternate term, information steward, emerged to clarify that the information is “owned” only by the people of the United States and that the federal government is only a “steward” on their behalf.
The information owner may not be a permanent member of the security staff or the authorization team, but does have some authorization responsibilities:
Establishes rules for appropriate use and protection of the subject information (e.g. rules of behavior).
Communicates the level of assurance required for the information on the system to the appropriate system owner.
Information system owner or program manager (PM)/information system steward
The information system owner or program manager (PM)46 has overall responsibility for the procurement, development, integration, modification, or operation and maintenance of an information system throughout the system life cycle. As with the information, the people of the United States “own” the information system, and the federal government is only the “steward” – hence the emergence of the new terminology of information system steward.
The information system owner/PM may not be a permanent member of the security staff, or a dedicated member of the authorization team, but does have significant responsibilities in relation to information systems security and authorization:
Develops and maintains the system security plan (SSP).
Ensures the participation of IS security personnel early in the IS development life cycle to assist in the identification and selection
46 In order to confuse the reader totally, the term program manager and system manager are also often used interchangeably. However, in most cases, the system manager will be associated with smaller, more mission-specific systems. For example, a PM may be responsible for a major program, such as the Joint Strike Fighter, to include the budget; while the SM will be responsibility solely for the ground system component.
of appropriate security controls, and provides guidance on the authorization process.
Authors, or ensures the authoring of all required MOAs to address security requirements between: ISs that interface, ISs that are networked and are managed by different DAAs, or ISs networked to non-agency entities.
Verifies the design of IS security for systems under his/her purview.
Verifies the implementation of security design in the developed IS by ensuring thorough security testing is performed.
Initiates protective or corrective measures immediately upon identification of security weaknesses/issues.
Takes all necessary and appropriate measures to resolve outstanding IS security deficiencies in a timely manner to establish a level of security necessary to achieve authorization to operate.
Ensures that required security controls are properly implemented and maintained throughout the life cycle of all ISs under his/her purview.
Ensures that the appropriate functional managers have properly identified and classified the data processed, stored, and/or transmitted by all the ISs under his/her purview.
Ensures that quality assurance reviews are performed routinely to minimize the risk of errors and preserve IS and data integrity for all ISs under his/her purview.
Monitors all contractors under his/her purview with access to agency ISs to ensure compliance with this and all other referenced policies and procedures.
Provides assistance, as needed, to security personnel during the accreditation and re-accreditation processes.
Assembles the authorization package for submission to the DAA or DAA representative for adjudication.
Information system security engineer (ISSE)
The information system security engineer (ISSE) is a critical component of the IA program staff and should be a permanent member, as opposed to the SME, who may be called in to join the IA program on an as-needed basis. The ISSE focuses on system security engineering as a defined process to capture and refine information system security requirements and ensure that these requirements are effectively integrated into information technology component products and information systems through “purposeful security architecting, design, development, and configuration.”47
The specific tasks of the ISSE include:
Coordinating information system security activities with the authorizing official and or the designated representatives, senior agency information security officers, security control implementers and common control providers.
Recommending and employing system security best practices.
Ensuring that security is integrated into the information system life cycle.
User representative
Users are found at all levels of an agency – from senior management to office staff. They are often on the front line for identifying mission/operational requirements and for ensuring compliance with the security requirements and security controls described in the system security plan. User representatives speak for the operational interests of the user community and serve as liaisons between users and developers throughout the life cycle of the information system. Although not dedicated to authorization support, user representatives often assist in the execution of the authorization process to ensure mission requirements are satisfied while still meeting the security requirements identified in the system security plan (SSP).
Users
Although they are listed close to the end of this section, users are often the most important component of an effective information security program. Information and information system users must know and understand the organization’s security policies and be held accountable for meeting their security responsibilities. User understanding and/or recognition of their security responsibilities can be accomplished in various ways.
Initial and refresher security awareness training is one of the most common means used to inform users about security requirements. Many organizations require personnel to sign a user agreement that includes the protection of information assets as a condition of employment, while others are required to sign a user agreement as a condition of allowing their connection to the organization’s network.
One highly successful method of ensuring that every user understands that security is a part of his/her job is to include it in the job description and make it part of the annual performance evaluation process.
Subject matter experts (SME)
The Six Sigma dictionary defines a subject matter expert or SME as an “individual who exhibits the highest level of expertise in performing a specialized job, task, or skill within the organization.” SMEs are important in the authorization process for those tasks that require a specialized expertise, e.g. implementation of technical controls or development of specific policies, such as disaster recovery and contingency planning.
Generally, SMEs are not a permanent part of the security team or the authorization team, but are called upon to execute a specific task for a specified period of time. In some cases, the SME may be termed an information system security engineer (ISSE).
Contractors
Too often, contractors are seen as “hired hands” to help federal agencies develop, acquire, operate, maintain – and certify and accredit – their information systems. Contractors, like their government or commercial clients, have a responsibility to ensure the security of the information systems and to comply with the security requirements of the information resources they use – whether these are on the premises of the client or within their own information systems.
Contractors provide critical services, but they can also present a risk. “Lack of oversight, combined with contractors’ failure to secure their networks, put sensitive government information at risk,” said John Grimes, US Department of Defense Chief Information Officer and Assistant Secretary for Networks and Information Integration, during a conference in Orlando, Fla. According to the 2007 annual FISMA report to the Office of Management and Budget (OMB), less than half of the 25 major federal agencies, including the DOD and Veterans Administration (VA), required the information systems used or operated by their contractors to meet the requirements of FISMA, agency policy, or the guidelines established by NIST.
But I’m just a small organization…
Small organizations are not exempt from meeting information system security requirements. In fact, smaller organizations may often need to make their information systems secure with limited staff, many of whom are required to fulfill multiple roles within the agency. A lack of personnel and multiple responsibilities assigned to a single individual make it even more important to understand the various roles involved in securing computers in larger agencies.
Can roles and responsibilities be delegated?
Sometimes it is just not possible for a single individual to execute all of the responsibilities associated with their assigned role. The organization may be too large or too geographically dispersed, or there just may be too much to do. In these cases, senior leadership may decide to delegate certain authorization responsibilities. Appropriately qualified individuals, even contractors, may be appointed in writing to perform the activities associated with almost any authorization role with the exception of certain roles, which are considered inherently government:
Chief information officer
Authorizing official
Certifying authority
Risk executive
Senior agency information security officer.
These roles have inherent US Government authority; consequently, the responsibilities associated with these roles must be assigned to government personnel only. Individuals serving in delegated roles may operate with the authority of agency officials within the limits defined for the specific authorization activities. Agency officials, however, always retain ultimate responsibility for the actions taken by those serving in delegated roles.
Systems security training and certification
Most programs do not start out with a ready-made staff, so it is important to determine the required skill sets to meet the overall objectives of the information security program. And don’t forget – training is a critical element to preparing the security staff for their responsibilities. Chapter 16 will cover the federal agency requirements for initial and refresher security training and certification in detail.
Developing and publishing plans and policies
Strategies, policies, and procedures are the structure’s finishing touches. They are an absolute must for any organization. They provide the virtual glue to hold the security program together. Imagine how any organization would operate without rules and guidelines? What would life be like?
The first step is to identify the design style for the particular structure represented by your organization and the guiding principles that your organization will follow to secure its information and IT. Our experience working with organizations – both government and commercial – has consistently revealed that just the thought of security policies tends to elevate the level of tension in any given situation. This boils down to a basic human characteristic – people generally do not like rules and they certainly don’t want to be restricted in their activities. One reason for the elevated tension level at the thought of policy is that the members of the organization all tend to have different security needs:
Management is concerned about cost and their return on security investment. They are also worried about the compliance word, thinking that security will be a speed bump to operations.
Others in the organization worry about still having the ability to accomplish their work without a lot of security restrictions.
Information system support personnel fear that stringent security measures will impede the capability of the network.
The second step is to firmly entrench guiding principles within the organization through creating strategies and policies within various control domains. These control domains – such as information systems security – represent the highest-level identification of policy. The specific policies within the individual domains specify the desired security course of action. The final step is to implement the authorized courses of action. The results of the implementation step are the operational standards, guidelines, and procedures that govern information systems security for the organization.
Ideally, information security strategies and policies should be the result of a formal policy design process that specifies who develops the initial draft, the policy review process, the approval process, and finally the implementation mechanisms.
NIST describes the basic purpose of security plans and policies as a means to provide an overview of the security requirements of the organization and describe the controls in place or planned for meeting those requirements. The security plans and policies also delineate the responsibilities and expected security-related behavior of the members of the organization. Security policies should emerge as the result of the structured process of planning adequate, cost-effective security protections. And most importantly, the security strategy and policies should reflect input from various organizational leaders and managers, including the information owners, the system owner, and the senior agency information security officer (SAISO).
The following flowchart depicts a decision-based approach to security and strategy policy development.
Figure 4: A decision-based approach to security and strategy policy development
Measuring progress
The final element in an effective security program is the use of the ongoing assessment. Typically, the ongoing assessment will enable the organization to respond more quickly and effectively to change as business models evolve, new technologies are developed, and new legislation is enacted.
But information systems security practitioners are often confronted with the following dilemma in evaluating security progress: If nothing occurs, is it proof that they have done as expected or that simply nothing happened? And if a security event does occur, is this proof that they have done a poor job? So how can their security progress be assessed in a more practical, consistent manner? The answer may be “security metrics”.
The right security metrics can help quantify and measure the effectiveness of security operations. The right security metrics can facilitate decision making and improve performance and accountability. The right security metrics can also help management decide where to invest in security and can identify non-productive, costly controls. But what are the right metrics? Metrics must be specific and measurable and must correlate directly to the business risks.
But selecting the right metrics is not the end of the story. Organizations still need to implement a long-term strategy for the collection and analysis of information security effectiveness metrics against established targets in information security effectiveness.
Many of the federal regulations defining security controls also have certain success metrics built into the control description. Where this is not the case, or where these metrics are not sufficient, assistance can be sought in other areas, such as international security standards.
ISO/IEC 27001:2005 (ISO27001) is one of the international standards that can provide guidance in developing, collecting, and analyzing security-related metrics. There are 133 controls in the ISO27001 standard that can be used to assess control effectiveness, but the standard also provides guidance on how to measure the selected controls’ effectiveness. In addition to this, ISO27001 requires the measurements to be comparable and repeatable, so they can be used time and time again, and compared on a regular basis to gain a better understanding of trends and progress.
Milestones from the “establishing a foundation” activities
Before proceeding to the next phase, the specific pre-certification and accreditation activities examined in Chapter 5, let’s take a final look at what you should achieve in establishing a basic foundation.
The leadership of the organization understands and supports the business case for information systems security.
An information systems security program is in place with a governance structure, staff, and budget.
Information system security policies are developed and published.
A program for continuous improvement is in place – determining the metrics, collecting and analyzing measurements, and implementing lessons learned into the environment.
By establishing a firm foundation for an overall information systems security program, you will also be setting the stage for a successful authorization program.
|
Further reading |
|
Barman, Scott. Writing Information Security Policies. Sams Publishing, November 2001. |
|
Peltier, Thomas; Peltier, Justin; and Blackley, John. Information Security Fundamentals. Auerbach: Boca Raton, FL, October 2003. |
|
Tipton, Harold and Krause, Micki. Information Security Management Handbook, 6th Ed. Auerbach: Boca Raton, FL, 2007. |
References
Government Accounting Office (GAO), Federal Chief Information Officers: Responsibilities, Reporting Relationships, Tenure and Challenges. July 2004. Available at http://www.gao.gov/new.items/d04823.pdf .
National Institute of Standards and Technology (NIST), Special Publication (SP) 800-18, Guide for Developing Security Plans for Federal Information Systems, Revision 1. February 2006. Available at http://csrc.nist.gov/publications/nistpubs/800-18-Rev1/sp800-18-Rev1-final.pdf .
National Institute of Standards and Technology (NIST), Special Publication (SP) 800-100, Information Security Handbook: A Guide for Managers. October 2006. Available at http://csrc.nist.gov/publications/nistpubs/800-100/SP800-100-Mar07-2007.pdf .
RSA, The Time is Now: Making Information Security Strategic to Business Innovation. Available at http://www.rsa.com/innovation/docs/RSA_strategic-security-APR.06.08_wo_mountain_print.pdf .
Westby, Jody R. and Allen, Julia. Article 2: Defining an Effective Enterprise Security Program (ESP). Carnegie Mellon University, 2007.