Don’t write with a pen. Ink tends to give the impression the words shouldn’t be changed.
—Richard Hugo, The Triggering Town
There is a tendency to lean for security practitioners to heavily on technical and physical controls. Machines do the same thing every time, forever and ever. Humans are more variable in their execution of tasks. However, we aren’t at the point where machines run themselves (I for one welcome our new robot overlords). Administrative controls are how you manage all this technology and associated controls in accordance with your stated security goals. We’ve talked about Courtney’s laws before. Now here’s one more.
Courtney’s third law states
There are no technical solutions to management problems, but there are management solutions to technical problems.1
There are many ways to interpret this (including having management fire all the tech staff and outsource them!) but let’s look at how we use documented processes to manage technology. This definitely includes how we manage technical controls, but administrative controls are also very powerful in managing normal IT operations.
Control Maturity
As a consultant, I listened to many clients tell me they had good processes, but they just didn’t ever write them down. They were sure everyone did the right things, but no one documented anything. When we began to check on what was actually going on, we discovered that there was a lot of divergence among what each person thought he was supposed to be doing. Worse, we often encountered complicated but critical tasks performed by a single person that were completely mysterious to upper management. When that person went on vacation or got ill, those tasks stopped. For some organizations, things were done differently, based on the time of the day and the amount of time that people had available. This may all be fine for some business and technical processes, but it’s precarious for security controls that you depend on. It’s also a deficiency finding during an audit.
Many organizations have a verbal work culture . They prefer face-to-face meetings and conference calls to e-mail and chat. They value getting together and hashing things out to investigate and decide on critical matters. There’s nothing wrong with this, but there should be some written processes for some things. For one, conveying information verbally is excellent for establishing a personal and deep connection with people. It’s also time-consuming and inconsistent. Some verbal processes simply do not scale. Once you get beyond a dozen people in a single discussion, meetings can last for hours. Many organizations now are globally dispersed, so setting up a conference call for status check-ins can get tricky when you have more than three time zones. Lastly, verbal processes do not leave behind permanent records that can be reviewed and analyzed later. If you missed any of these big meetings and no one took minutes (converted verbal to written), then you are short out of luck. Also, no records means no metrics.
Capability Maturity Model
One of the ways that organizational processes are assessed is with the Capability Maturity Model (CMM ). The CMM was developed to evaluate and rate military contractors on how well they might perform on software projects. The CMM helps determine things like how repeatable a process is, whether a process can be taken over by another individual, and how a process can be measured. To do this, the five-step scale shown in Figure 13-1 was developed.
Figure 13-1. Capability Maturity Model
The CMM is so handy and powerful that some auditors (including myself) have used it for rapid assessment of an organization’s security processes. Consider the security of an organization with no published security policy—where users are added and removed haphazardly. Patching takes place when someone gets around to it rather than on a schedule. Think about how hard it would be improve processes if there is no consensus on how they are performed. It may sound like I’m beating a dead equine here, but one of the biggest challenges I’ve had in moving organizations to a secure and audited state was convincing them to document their processes (and follow those documents).
The Power of Good Admin Controls
Some people say that using documented processes and following checklists slows them down and they get less work done. In reality, having defined methods for performing complex tasks build accuracy and speed. There are less errors (and less redoing) and better understanding of the process. With documented processes, work can be handed off to newcomers with less-handholding and training. Finally, documented processes are easier to automate because the algorithm has already been laid out.
Keep Them Updated
To be useful, administrative processes need to be reliable or they are worse than useless, they are misleading. An unsuspecting admin using an outdated process document could easily cause major system failures or create new security vulnerabilities. Documents need to be kept current to match the relevant tasks and environments. You should not carve administrative processes in stone; they should be fluid and always be checked and updated as needed. The first step in making sure this happens is assigning ownership to a process. The owner does not need be the one updating the process either, only to ensure that an update is performed. For example, ownership of the move/add/change user process could be given to manager of the helpdesk. She could then assign the updating of the procedure as needed. Managers need to ensure that their staff is given the responsibility and the time to update documents. An old management trick is to assign updating the process to a new hire that is paired with a veteran to assist them. As the newcomer learns the process, they also can work to update the document. Many technical document management systems can be set up to e-mail reminders to the owner periodically to review and update procedures.
Some organizations use internal wiki sites to store all their administrative policies . Since wikis are designed to support living, evolving documentation for a large number of people, they work well for this kind of thing. All changes are visible as well as who performed them and when. Policies can be set up to hotlink standards and procedures. Explanatory documents and external sites can also be linked as needed.
Differences in Documents
You read about the different kinds of administrative controls back in Chapter 11, on policy, so let’s dive deeper. There is a top security policy document for the organization, which defines the high-level goals. In Figure 13-2, you can see how you can have more policies for specific control objectives with specific audiences in mind.
Figure 13-2. Example of policy relationships
This is not the perfect list. As things mature and go obsolete, you need to add and drop policies around different control objectives. In addition, you may choose to break down these control objectives into different groups or combine them in other ways. The coverage and upkeep is what is important, not the individual documents.
From these policies, you can build up the standards to describe how technology should be used to support the policy. The standard can lay out minimum baselines for settings, acceptable technologies, and responsibility matrices.
Below the standards are the procedures, which are the run books to tell people step-by-step how to perform tasks. Procedures can be detailed with screenshots and specific commands or they can be checklists for implementation. Many organizations develop standardized templates for procedures, with version numbers, to help people keep things straight. There are plenty of examples of policies, standards, and procedures for the specific control objectives. Let’s jump right into some of those critical IT operational policies the support security right now.
Critical Admin Control: Asset Management
You may remember how important inventory is from the chapters on risk analysis (Chapters 3, 4, and 5). You’ll want a policy covering this and making sure responsibility is assigned to get it done. Next is a sample policy describing what should be included.
Sample Asset Management Policy
ORGANIZATION will identify, track, and record all IT and IT-related assets. The IT Operations Department will be responsible for maintaining standards and procedures related to IT assets. These standards will include:
IT assets and IT-related tracked
Asset details tracked
Baseline workstation and server configuration standards
Approved software applications
Asset inventory procedure
The asset inventory will be updated at least quarterly and be subject to both internal and external audits.
Sample Asset Management Standard
As you can see, this policy calls for additional standards and procedures. You can have standards and procedures without them being required to be written by the policy. However, if you want them to be created, you should mandate them in the policy. It’s in both IT and security department’s interest to have a good asset inventory. Here is a snippet of what should be included in the asset standards.
Assets tracked will include:
Confidential data
Contracts, support agreements, and legal records
Software assets and their associated licenses
Physical assets such as workstations, laptops, servers, cell phones, network devices and security equipment
Portable digital media such as floppy disks, tapes, external drives, Bernoulli boxes, and USB sticks
Local and offsite virtual guest imaged, saved machine images, and the virtualization servers
Internal and third-party tokens, cryptographic keys, certificates, and passwords for accessing offsite data resources
Asset details tracked:
Hardware: Brand, make/model, MAC address, Serial #, Location, Owner
Tokens & Certificates: Code key, Affiliation, Owner, Expirationdate
This policy will be reviewed on an annual basis and may change regulations or requirements.
Critical Admin Control: Change Control
When introduced into environments for the first time, some organizations see Change control as a major pain in the posterior. I’ve heard the complaints: “Oh, the paper work! And getting approval before IT does anything? Do you realize how much that will slow things down? This is just like auditors, making us jump through hoops just to do our job!” In fact, there is proven business value in change control.
Change control is a foundational control for SSAE 16 SOC 1 but is also a requirement in PCI DSS and ISO 27001. Change control is a powerful control for ensuring that systems are maintained in a known, tested state. Since updates, patches, and new configurations are performed in standard, predictable ways, IT operations are efficient and stable. The IT Process Institute found that 80% of unplanned outages were because of poorly planned changes.2
Change control means there is a documented process that governs all modifications to scoped systems. Access to those systems is minimized and monitored. Tools should record all changes for later review by system owners and auditors. In general, change control forces IT to pay attention to what they’re doing. Figure 13-3 describes a typical flow for change control.
Figure 13-3. Change Control Process flow
Sample Change Control Policy
The purpose of the Change Control Policy is to ensure that our organization’s IT department can deliver quality updates to our internal customers. Good change control accommodates change through proven processes, ensuring clear requirements and reliable results. Change control is done to reduce the risk of unauthorized changes, unplanned outages, failed changes, emergency changes, and operational delays. Policy requirements:
Requests for changes to critical IT systems will be coordinated in a timely, transparent, and efficient manner
There is a Change Control Board comprised of representatives from IT support, IT applications, IT operations, and the departments being served
Changes can be proposed to the change control board by anyone within the organization through the IT support help desk
Change requests must include reason, systems affected, back out plan, location of code for change
Whenever possible, proposed changes will be tested and the test results submitted along with the change request
Changes to Production Hosted systems must be approved by the Change Control Board
The Change Control Board will meet weekly, or sooner as needed, to review and approve proposedchanges
Proposed changes are assessed for potential impact to eliminate unnecessary or disruptive changes are minimized
Changes will be carried out solely by the IT operations team - Changes must be verified to be complete and correct by the change requester
Unauthorized changes will be considered a security policy violation and individuals will be held accountable for violations
These Change processes will be subject to internal and external audits.
The Operations group will maintain a standard describing proper change management processes. This standard will include the following components:
Roles and responsibilities
Requests
Change planning and testing
Evaluation: approval/rejection
Maintenance windows
Verification
Rollback
Documentation
Emergency changes
This policy will be reviewed on an annual basis and may change regulations or requirements.
Change Control Standards
There should be standards around change control that support the policy by defining key items within change control. These standards should include:
What constitutes a change?
Application changes?
Hardware changes?
Operating system changes?
Network changes?
Facility changes?
How are changes classified?
How is risk of change effects determined?
Experience with change?
Impact to neighboring systems?
Scope of change?
Time to complete change?
Systems involved in change?
Quality Assurance review of change?
What are emergency changes and how can the normal process be bypassed for an outage but documented and explained
What are low-risk pre-authorized changes that do not need approval?
What is an acceptable back out plan?
What are the acceptable change windows?
Change Control Tracking
Part of the change control process is detecting if anyone bypassed it. There should be additional controls in place supporting the change control process that monitor for unauthorized changes. A number of technical controls can be used to keep track of changes, including file integrity monitoring or cloud configuration logging.
Because of the utility of change control, it’s a good idea to track metrics around the process to demonstrate how effective the system is for improving IT and security operations. Here are some useful metrics to consider:
The number of changes that meet requirements (successful change)
System uptime
The number of unauthorized changes
The number of emergency changes
The average time to perform change
Outages caused by changes
The accuracy of change time estimates
Critical Admin Control: Application Security
Application security is big and important—so much so that entire books and security certifications exist on the topic. Application security is critical, and I don’t want to omit it, but I don’t have the space to do it justice either. So you should just be aware that I’m skimming the surface of this major area of security.
Application security refers to writing and acquiring software applications that meet a security standard. It involves security in designing the software, how the software is coded, how the code is protected, and how secure the code is in different risk environments. Next is a sample high-level security policy on application security that should give you an idea of the expectations. The standards and procedures related to application security can get deep, but are worth looking into if you do internal development of applications that process or store confidential data.
Sample Application Security Policy
The ORGANIZATION will maintain and follow secure application development and maintenance processes to minimize unauthorized access, modification, or downtime to ORGANIZATION applications.
To support this objective:
The Security Department and the Software Development department will develop, publish and use secure coding standards based on industry best secure development practices
Software Developers will have adequate secure application education & training
Software Developers will use a Threat model and will be educated on common attacks, such as the Open Web Application Security Project (OWASP) Top Ten Vulnerabilities, to inform their threat model.
There will be adequate separation of privileges between development, QA, and production environments.
Development and Test data will not contain confidential information or personally identifiable information.
Source code will be protected from exposure, tampering, and loss.
As part of software release, the Software Developers will ensure that test data and accounts are not present.
On an ongoing basis, the Security department will facilitate third-party security tests of in-house developedapplications
Software Vulnerabilities will be tracked, risk rated, and remediated.
The Security department will conduct periodic reviews to test compliance against this policy.
This policy will be reviewed on an annual basis and may change regulations or requirements.
Application Security Standards
Many application standards can flow from the preceding sample policy. One that comes to mind is a standard around vulnerability assessment, which might work well as a RACI diagram, as follows.
Function | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
Vulnerability assessment | Security | Development | QA | App owner |
Vulnerability scoring | Security | Development | QA | App owner |
Remediation | Development | App owner | QA | Security |
Verification of remediation | Security | Development | QA | App owner |
A second important standard would be the guideline for developers to follow, which could look like the following sample.
Sample Secure Software Design Standards
Sessions and authentication data will be protected from impersonation, unauthorized modification, and sessionhijacking
Web applications will facilitate client-side security through the use of browser directives
User error screens will not reveal confidential or detailed system configuration information
Application authentication mechanisms will be robust and resist brute-force guessing attacks
Applications will validate input and output data
Administrative or configuration data will not be visible to unauthorized users
Software Acquisition
Just as important as developing software that is secure to a tolerable level of risk, is acquiring software that meets that standard. The acceptable usage policy guides users in making sure they only use approved, known safe software. Likewise, the IT department should work with the security team when on-boarding major software applications, especially if those applications interact with scoped systems or data.
To make this job easier, there should be a software acquisition policy that requires the security department to analyze and approve new IT systems. There can also be an accompanying standard that provides criteria for measuring the security and acceptability of new applications. This standard could include things such as the following:
Applications must support existing organizational control objectives and policies. For example, authentication systems much support organizational password standards, logging systems must support organizational logging standard
Software must be third-party tested for security vulnerabilities with no significant vulnerabilities present
Internet-facing web application systems must be tested against the current OWASP top ten vulnerabilities with no significant vulnerabilities present
Software should be capable of producing human-readable configuration information for audit and configuration review
Manufacturer must disclose all maintenance and administrative access modes including any “developer backdoors” or automated callbacks outside of the organization
Applications performing security functions must have up-to-date product assurance certification of advertised functionality from well-known independent evaluator such as Underwriter Labs (UL), Federal Information Processing Standards (FIPS), ICSA CyberTrust, or National Information Assurance Partnership (NIAP)/Common Criteria.
Critical Manual Control: Record and Media Management
Your organization’s records are a critical asset, so you should have policies and procedures in place to protect them. Some policies distinguish between paper and electronic records, while others combine into a single policy.
Critical records almost certainly include e-mail and internal messaging systems, as these are the kinds of records that are relevant in litigations and criminal investigations. When it comes to lawsuits, it’s always better to be able to produce the relevant, and only the relevant, records when requested by the court. Organizations that are unable to provide records in lawsuits are often viewed by judges with suspicion. Organizations can risk legal penalties and negative inferences in the case for not being able to find critical records. This means that the security and IT departments should work with legal counsel to develop a realistic record retention schedule. Business norm in the United States is a retention period of seven years. The IT department should make sure that they have adequate capacity and technology to be able to store and find records.
Speaking of lawsuits, quite a few breach negligence cases stem with an organization losing or improperly disposing of things like laptops and backup tapes. Media, such as drives and tapes that contain confidential information needs to be properly tracked, secured, and when the time comes, thoroughly destroyed.
Sample Record and Media Management Policy
ORGANIZATION recognizes that record management is important. To meet that goal, ORGANIZATION will have standards and procedures in place to inhibit the intentional or negligent withholding, alteration, or destruction of internal records. Records and media containing confidential and personal private information will be protected against unauthorized exposure. To meet these goals, the ORGANIZATION will do the following:
Critical records will be identified and documented in a standard and communicated to all relevant persons within the organization
Location and responsibility for records and media will be tracked
Record retention standards that are feasible and appropriate to the organization will be defined and approved by legal
Records will be protected from physical and electronic threats with controls
Records will be stored in a manner that they can be retrieved quickly when requested. A procedure for record retrieval will be written and updated.
Data archival and destruction timelines will be tracked and records scheduled for destruction when due.
Media and records will be securely erased or destroyed in such a manner as to make inadvertent recovery impossible and intentional recovery impractical. Standards will be developed to describe the secure erasure and destruction processes.
Procedures will be written for records and media being transported off premises
This policy will be reviewed on an annual basis and may change regulations or requirements.