Rhand Leal What do diverse situations like the Battle of Trafalgar (1805), the Cooley–Tukey FFT algorithm (1965), and the multi-sided market competition have in common? They are all examples of big or complex problems divided into smaller and more manageable pieces to reach a winning solution. This is a strategy called “Divide and Conquer.”
Like war, signal processing, and marketing competition, information security also deals with a complex situation: protecting information in all its forms and in all locations where it is stored or passes through. In this article, I will present you with a concept based on “divide and conquer” that can be very useful, especially for bigger companies, while implementing ISO 27001 security controls: the Work Breakdown Structure (WBS).
What is a Work Breakdown Structure?
Originating from project management practices, the Work Breakdown Structure (WBS) is defined by the Project Management Body of Knowledge (PMBoK) as “a deliverable-oriented hierarchical decomposition of the work to be executed by the team.”
A deliverable is any tangible or intangible object produced by a project that is intended to be delivered to a customer. Examples of deliverables are a product, a service, or data. Deliverables may be decomposed into multiple smaller deliverables, also called components (e.g., parts of a product, functionalities of a service, or chapters in a report).
Normally, a WBS is presented graphically in the form of a tree of elements, with the main deliverable at the top, the deliverable components in the middle part, and lists of activities to produce the deliverables at the bottom. Another way to present a WBS is as an indented list. See examples of these presentations at the end of the article
In terms of information, deliverables and components are specified in terms of requirements to be fulfilled, while activities are specified in terms of resources needed, like time, equipment, and cost.
In the ISO 27001 security controls context, we can have the following examples of deliverables:
- Product: data center vault room
- Service: network traffic monitoring service
- Data: assets inventory database
- Activity: server configuration
Design principles
While using a WBS to plan a security control, some rules should be followed to avoid excess or lack of detail, since both can negatively affect the implementation effort:
- Focus on outcomes, not actions. To make your WBS more understandable and useful, define as many elements as possible as outcomes to be achieved. Besides reducing the number of actions to be tracked, more outcome elements provide better capacity to identify results that may compromise the security control strength, or performance.
- Group activities in a manageable way. Avoid defining for a single deliverable an activity, or group of activities, that would require the allocation of many resources. A good “rule of thumb” is to limit the effort required by a single deliverable to less than 80 hours.
- Pay attention to detailing level. Though you can make a WBS with any level of detail, try to keep yours between three and seven levels, with the more detailed dedicated to deliverables with high cost or high risk.
Benefits and problems of using a WBS
Some benefits associated with developing a WBS are:
- Better knowledge of the required steps. The WBS development is a group effort, where each person involved has needs to be fulfilled in order to achieve the expected results. This situation forces everyone to work to clarify ambiguities, bring out assumptions, and raise critical issues that can impact the control performance.
- Improves accountability. The detail level provided by a WBS makes it easier to establish people accountability, since no one can hide under a “broad specification.”
- Improves commitment. As a group work, the WBS development helps create a sense of ownership and involvement with the control implementation.
Some problems you must be aware of:
- Effort requirement. Depending on the size or complexity of the control to be implemented, the WBS development can take quite a lot of time. And, the more people involved, the more effort involved to balance the many needs and requirements.
- Increase in complexity. The initial developed WBS will rarely remain unchanged. As control development and implementation goes on, some adjustments may be necessary, and the impact of such changes must be evaluated.
WBS applied to security controls
Since nothing is better than a good practical example, let’s see a hypothetical WBS for implementing security controls in an information system:
- Information System
- Hardware:
- Server
- Desktop
- Mobile
- Software:
- Operational system
- Application
- Network:
- Cabling (control A.11.2.3 – Cabling security)
- Wireless communication
- Remote access
- Routers
- Network segregation (control A.13.1.3 – Segregation in networks)
- Define network perimeters
- Define network traffic rules
- Data:
- System data
- User data
- Organization data
- Information classification (control A.8.2.1 – Classification of information)
- Inventory of Assets (control A.8.1.1 – Inventory of assets)
- Define assets categories
- Assets owners (control A.8.1.2 – Ownership of assets)
- Define assets owners
- Define owners responsibilities
- Asset classification (control A.8.2.1 – Classification of information)
- Define systems classification according to the highest classified information processed by the system
- Network segregation (control A.13.1.3 – Segregation in networks)
- Hardware:
Here it is in graphic form (actions are identified by the red font):
Build reliable strongholds one brick at a time
Implementing security may sound like a huge challenge. And it really is, but you don’t need to embrace it all at once. By doing it one piece at a time, you can optimize the effort to ensure each small piece is designed as strong as possible and implemented with all due care, minimizing the chance that all your efforts may be compromised by a situation you could have avoided.
Use this Conformio compliance software to guide you through your ISO 27001 project.
