The COBIT Align, Plan, and Organize domain includes basic details of an organization’s requirements and goals. This domain answers the questions “What do you want to do?” and “How do you want to get there?” The information in this phase is still high level. Even at a high level, it is important to understand the risks and threats clearly. You review how you are going to manage your IT investment such as contracts, service level agreements (SLAs), and new policy ideas. An SLA is a stated commitment to provide a specific service level. For example, an SLA could state how often a supplier will provide the service or how quickly the firm will respond. For managed services, the SLA often covers system availability and acceptable performance measures. It’s also important to look at where or how the system will operate to determine the SLA. SLAs are important to ensure that all parties know their obligations. There are different types of service levels that apply to contracts versus what you need to deal with day to day. The Deliver, Service, and Support domain helps you define and manage day-to-day SLAs. In the Align, Plan, and Organize domain, you are primarily concerned with the type of equipment and services you are acquiring and how to hold a supplier accountable for those deliveries.

A contract must provide the ability to ensure a supplier meets its obligations. The SLA language in a contract must provide clear monitoring and enforcement rights. For example, consider the 2013 breach of Target stores. Although this is an older breach, it is one of the major events in cybersecurity history and still worthy of consideration. Between November 27 and December 15, 2013, hackers accessed the credit card information of 40 million customers. Later it was discovered that an additional 70 million customers’ personal information was also accessed by hackers. It’s been widely reported the hacker gained access through the supplier who maintained the company’s heating and air conditioning systems. Simply having a contract with the supplier wasn’t enough. Target had an obligation both to limit the supplier’s access while on its network and to monitor access sufficiently to ensure the contract was being enforced. These are general industry norms. Either one or both of these did not occur.

A key understanding in this life cycle phase is the understanding of threats, vulnerabilities, and risks. These three concepts are addressed in different forms throughout this text; however, a basic understanding is essential to scope the build effort. To understand these concepts, consider the following high-level definitions:

• Threat—A human-caused or natural event that could impact the system
• Vulnerability—A weakness in a system that can be exploited
• Risk—The likelihood or probability of an event and its impact

As an example, a common IS threat would be a hacker trying to break into a system. A vulnerability would be a weakness in a system that allows the hacker to gain unauthorized access. A vulnerability could be a misconfiguration, bug, or flaw in the system. A risk is a combination of the likelihood that such a misconfiguration could happen, a hacker’s exploiting it, and the impact if the event occurred. Consider a non-Internet-facing system for ordering office supplies. Why might you think the risk is low? Although a misconfiguration may be possible, systems not on the Internet are less likely to be hacked. Additionally, unauthorized access to the office supply system would most likely have little long-term impact on a company.

Other examples may be of higher risk and require significant investment. An example of a natural threat would be a hurricane. A vulnerability may be a lack of a recovery site. If your main data center, for example, is damaged, where would you go? The risk may be high for a business that relies on Internet orders, especially if the business is located in Florida, which is prone to hurricanes.

The COBIT Build, Acquire, and Implement domain addresses schedules and deliverables. The basic build occurs within this phase. The build is where the security control is built and policies and supporting documents written. The build is based on the requirement created in the Align, Plan, and Organize phase. The quality of the security controls that are built depends on the understanding of the threats, vulnerabilities, and risks. The deeper this understanding, the better the controls. The more detailed the requirements, the more easily the build will go. The more details included in the Align, Plan, and Organize phase, the easier the Build, Acquire, and Implement phase will be. The SLA becomes an important consideration of the build because it determines the type of solutions that will be selected.

Additionally, the ability to manage change is critical in this phase. Often, changes known as upgrades are made to existing systems. That means changes have to be timed perfectly. This is to avoid disrupting current services while new services are added. Often this will occur during off-hours such as weekends or overnight. Plans have to be put in place to back out the change in the event of a major problem. Understanding the impact of change and knowing how to recover if something goes wrong are parts of change management.

By the end of the Build, Acquire, and Implement phase, you have acquired and implemented your equipment. You have controls built into the systems. You have policies, procedures, and guidelines written. You have teams trained.

In the COBIT Deliver, Service, and Support domain, the staff tunes the environment to minimize risks. It is in this phase that you collect lessons learned. By running the systems, you learn what’s working and what isn’t. This is where you apply those lessons learned to improve operations. This could mean adjusting controls, policies, procedures, contracts, and SLAs. It is here you analyze data from the prior phase and compare it with day-to-day operations. You also perform internal and external penetration testing and, based on the results of those tests, make critical adjustments in areas such as perimeter defense, remote access, and backup procedures. You review contracts and SLAs for validity and modify them as needed.

This phase requires regular meetings and good communication with your vendors. You must quickly identify any issues with the vendors’ capabilities to meet SLAs. Typically, a vendor provides its record for meeting SLAs. You compare the vendor’s report to your organization’s internal reports. If you rely heavily on the vendor, you should meet monthly to compare records and recap incidents during the month. It is important that SLAs also be explicit. Failure to clarify precisely what services are provided and how they are provided can lead to confusion and dissatisfaction from both the customer and the vendor.

In this phase, the day-to-day operations are managed and supported. You manage problems, configurations, physical security, and more. If you plan correctly and implement the right solution, your organization sees value.

After evaluating the ISS management life cycle, you can see that ISS focuses on specific types of controls at specific points within the system. Testing and monitoring of controls occur, and the results are analyzed for effectiveness. The oversight of the COBIT Monitor, Evaluate, and Assess domain looks at the big picture. Are your controls and supporting policies and procedures keeping pace with changes in technology and in your environment? This phase looks at specific business requirements and strategic direction and determines whether the system meets these objectives.

Internal and external audits occur during the evaluation phase. Audits also take place through all testing in this and prior phases to ensure requirements are being met. This may include penetration testing by a third-party trusted agent. The testing performed during this phase must be comprehensive enough to encompass the entire ISS environment. The level of additional security testing will depend on business requirements and complexity; for example, if your requirements include regulatory compliance, include appropriate control tests. You should also evaluate the incident response process.

Audits are independent assessments. The more robust the self-assessment process, the fewer the problems that will be discovered by an audit. Independence is a relative term. No one is truly independent. Consider this: Everyone belongs to a family. Everyone lives in a town or city. Everyone has a multitude of private and business relationships. People may feel comfortable criticizing politicians but suddenly uncomfortable criticizing a teacher who has the power over their final grade. It’s human nature that the closer the relationship, or the more control someone has over your well-being, the less likely you are to criticize. Yet in business, this honest view of mistakes is essential to success.

The concept of independent audits (or assessments) is that the further one is away from the actual transaction, the more unbiased and independent the opinion that can be obtained. In other words, it’s hard to criticize your own work. However, the more you understand the work, the better your chances are, generally, of finding out what went wrong. To balance these potentially competing interests, there is usually a series of assessments and audits. The following lists the most common types of assessments and audits:

• Self-assessment—This is typically in the form of quality assurance (QA) and quality control (QC).
• Internal audit—This consists of reports to the board of directors and assesses the business.
• External audit—This is done by an outside firm hired by the company to validate internal audit work and perform special assessments, such as certifying annual financial statements.
• Regulator audit—This is an audit by government agencies that assess the company’s compliance with laws and regulations.

Although COBIT is widely used and respected, it is not the only standard relevant to the information systems security management life cycle. The International Standards Organization publishes ISO 38500, “Information Technology—Governance of IT for the Organization,” which provides guidance for managing IT governance. This standard is broader than just information systems security, but it includes and is applicable to information systems security management.

This standard was last revised in 2015. It specifically addresses monitoring of resources and auditing, both of which are clearly information systems management functions. This framework sets out six principles for corporate governance of information technology:

• Responsibility
• Strategy
• Acquisition
• Performance
• Conformance
• Human behavior

Clearly, each of these is as applicable to information security systems as it is to IT in general.