routine oversight and audit. Compliance is not optional, and well-structured organizations track compliance with procedural steps.
In certain environments, procedural compliance is achieved by using various separation-of-duties methods. For example, in cloud environments, an organization might require that every action applied to the cloud environment is performed by using an approved configuration management script, such as a Chef recipe or a Puppet task, while further dictating that the author of a script cannot be the same individual who approves the script.
Note, too, that the word procedure is also used by software developers and programming languages to refer to a unit of software, such as a function, a subroutine, or a stored query.
Baselines
Some organizational cultures refer to a tailored version of a standard as a baseline. Typically, tailoring of a standard reduces the requirements set by the standard; if additional requirements are needed, it is best practice to put them into some other document, such as a local or internal standard. Once a baseline has been established, any deviation from the baseline should be formally approved through the organization's change management practice. As with standards, baselines establish a compliance expectation.
As a subset of baselines, security baselines express the minimum set of security controls necessary to safeguard the information security requirements and properties for a particular configuration. Scoping guidance is often published as part of a baseline, defining the range of deviation from the baseline that is acceptable for a particular baseline. Once scoping guidance has been established, then tailoring is performed to apply a particular set of controls to achieve the baseline within the scoping guidance.
The term baseline can also refer to a reference set of systems components; the inventory of software installed on a server by the vendor, at the time when the server is first turned on and configured, is an architectural baseline.
Guidelines
Guidelines are necessary when an organization determines that some level of flexibility in implementation is necessary to achieve business objectives. Guidelines often rely upon best practices for a particular discipline or are the codification of an organization's experience in a particular area.
Guidelines may be useful when a range of options exist to achieve a particular control objective and it is acceptable to encourage creativity and to experiment to compare the effectiveness of different options. Guidelines may also be useful when the organization's staff has a broad base of experience and a shared vision for an outcome. In that case, the explicit directions of procedures, standards, and baselines may provide too much structure and impede the adoption of more efficient methods.
There are many sources of guidelines for information security practice. Certainly, the CISSP Body of Knowledge is one, as it reflects a broad range of security practices but is not prescriptive inside an organization's information security environment. The ISO/NIST/ITIL frameworks are often leveraged as guidelines; however, they may become policies or standards if the organization has a compliance expectation. Other sources of guidelines include manufacturers' default configurations, industry-specific guidelines, or independent organizations such as the Open Web Application Security Project (OWASP) work in software development.
There is no single, correct answer for the number and breadth of policies, standards, baselines, procedures, and guidelines an organization should have. Different regulatory environments, management expectations, and technology challenges will affect how the organization expresses and achieves its goals.
Periodic Audit and Review
There are two major shortcomings with most human-facing procedural and administrative controls for security and risk mitigation. The first is that in their human-facing form as an end product, they invariably end up being anywhere but right at the point of contact between the humans involved and the vulnerable system element the administrative controls are designed to protect. Policies and procedures distributed on paper or as email attachments end up being lost or buried in a desk drawer or folder tree and forgotten about. Signs and warning placards catch the eye during the first few days or weeks after they've been posted, but after a while, the human mind tunes them out; they're just part of the visual clutter of the background.
Because of these shortcomings, it's good to audit your administrative controls with an eye to separating them into two major categories: those that direct or require a real-time action, such as emergency notification and incident response; and those that provide longer-term guidance for behavior, such as inappropriate or unauthorized use of company-provided assets and resources. That first category represents opportunities for some smart investment to ensure that just the right amount of policy guidance, direction, and constraint is at the right fingertips at the right time.
Audits
Audits are structured reviews that compare a set of security and risk controls, and the systems that they protect, against a controlled administrative baseline. This baseline can include inventories, performance standards, compliance standards and requirements, quality measurements and standards, or process maturity models and standards. Informal audits can be used as part of troubleshooting, to improve organizational knowledge of its own systems, or to gain insight into opportunities for improvement. Informal audits do not require the use of outside auditors who are trained and certified for the type of audit being performed. Formal audits, by contrast, are typically conducted to meet legal, regulatory, or contractual compliance needs, such as those imposed by governments or the organization's finance or insurance providers. Audits produce a report, which is typically addressed to the management or leadership levels of the organization that requested the audit. Although the structure of these reports can vary considerably, they usually include an executive summary of the audit, key findings, issues or discrepancies that need to be resolved, and any recommendations as appropriate.
Audits can place a significant burden on information security operations and support teams. Typically, extensive preparation is required to identify the audit baseline or standards that will be used and ensure that the auditors will be able to access all of the items being audited. Workspaces will need to be provided for the audit team, and the auditors may require special access and privileges to the IT elements being audited. They may also need to have IT systems to use for gathering and organizing audit data and to produce and report their findings.
Exercises and Operational Evaluations
Things change; that is the only constant we have in life. The proficiency and currency of the tacit knowledge within your team changes with time; the threats change how they seek opportunities that meet their needs and how they attempt to exploit them. Your systems change, and sometimes not for the better as they age in place. For these and many other reasons, it's wise to establish a process of exercising and evaluating security and risk mitigation control systems, in as realistic an operational setting as you can manage without unduly disrupting normal business operations. A properly designed and well-considered exercise and operational evaluation plan should gain the support of management and leadership; their guidance and sponsorship are crucial to make time and talent available to plan and conduct such activities. Be sure that each plan closes with a thorough post-event debrief and analysis, producing documented recommendations or action items to finish the job of learning what each exercise or evaluation just finished teaching you and the evaluation team.
PARTICIPATE IN CHANGE MANAGEMENT
Change Management or Configuration Management?
These
