Addressing Information Security in Business Analysis with SABSA

In this article, I would like to show how the SABSA (Sherwood Applied Business Security Architecture) framework can be applied to address information security as part of business analysis.

In the business analysis domain, information security was not of much interest throughout the last decade or so. However, an incredible rate of development in mobile technology and the penetration of mobile computing into the corporate environment has increased the importance of information security.

This has led me to explore how the SABSA framework can be helpful to a business analyst in addressing the security needs of the business. While I have found quite a lot of value in applying the ITIL framework, I think the SABSA framework aims to fill the gaps in the ITIL framework regarding information security.

The Governance Pyramid

First of all, let’s consider governance. Governance in any business is not a simple set of internal rules. Each business has its own policies and procedures governing the functioning of the business, and they form the bottom layer of the governance pyramid.

Best practices are incorporated to improve the functioning of the business and make it more competitive and sustainable. These practices make up the middle layer of the governance pyramid.

The top layer consists of industry regulation and laws coupled with standards to which businesses have to adhere.

Each of these layers has specific information security requirements. However, they are not consistent across these layers as there is no underlying system that translates multiple requirements into a cohesive set of requirements applicable to a particular business and covering the business objectives.

The SABSA framework serves as a system to ensure that the information security needs of an organisation are thoroughly understood, designed, delivered and well supported along with the IT infrastructure.

The Four Ps

Successfully ensuring information security is not just about using the best hardware and software. It requires a broader view that incorporates the four Ps: People, Processes, Products and Partners.

 

Internal policies, well-designed processes with a focus on information security, properly configured hardware and software products, and well maintained relationships with partners and suppliers create a coherent set of information security practices within the business.

How SABSA Empowers a Business Analyst

As SABSA is an enterprise security architecture framework, it can be used for the development of business solutions at any level of granularity and complexity.

The value that SABSA creates for business analysis lies in the questions that have to be answered before beginning a solution design. These questions help specify the solution more precisely and avoid costly mistakes and low user satisfaction.

The SABSA model has a layered structure as shown in the diagram above. Each layer provides a set of questions asked from different viewpoints.

The contextual layer guards business analysts from jumping to a conclusion at the start of a project. It gives a business analyst the following information:

• business context
• business asset taxonomy
• business motivation
• affected processes
• users involved in the processes
• location where the solution is required
• time when the solution needs to be available.

The common questions to ask here are:

• Why does the business want this solution?
• What type of solution should be built?
• What aspects of business security should be addressed?
• How will the solution be used?
• What business processes and data require information security?
• Who will use the solution (types of users, their mobility and their numbers)?
• What credentials should be allocated to users to enable the use of the solution?
• Where should the solution be located?
• What security measures should be in place to ensure the secure use of the solution?
• What are the solution’s relationships with the existing business landscape?
• When will the solution be used (usage patterns, critical business days, etc.)?

The conceptual layer is concerned with the selection of logical and physical components that will be used to build the solution later. Here the business analyst learns about:

• business risk strategy
• control objectives
• the process mapping framework
• IT architecture strategies
• roles and responsibilities of stakeholders (users, service providers).

The questions revolve around the security principles that will be used within the solution, and include the following:

• What business information should be protected within the solution?
• Why is the protection of the identified information important?
• How can the required protection be achieved at the business process level?
• Who will be involved in security management during the production use of the solution?
• Where should the protection be applied (boundaries)?
• When is the protection sufficient (measurement)?

Proceeding downwards, we come to the logical layer. This layer helps the business analyst determine:

• the current inventory of IT assets (CMS means Configuration Management System. See ITIL v.3 for more detail)
• risk management policies
• processes and enabling IT services (service catalogue)
• entities and trust models
• interaction flows between locations
• schedule of events (start time, duration, end time).

In practice, the contextual and logical layers listed above are the most difficult and few businesses are ready to demonstrate what they have in place. The reason for this awkward state is that quite often the IT department does not have a business service catalogue and a supplementary configuration management system detailing all IT assets.

The following questions should be asked at this point:

• Why does the specified business data require protection (policies, regulation)?
• What business data should be secured?
• How should the business data be protected?
• Who will be involved in securing the data? What will be their relationships?
• Where do the security measures apply (security domains and their boundaries)?
• When do the security measures start to apply (deadlines, schedules)?

The logical model ensures that the solution can satisfy the business objectives and are realistic from an engineering perspective.

Once the logical security modåel is understood, it is time to look at the physical layer. The logical model of information security is translated into the physical security mechanisms, and this layer helps the business analyst learn:

• the business data dictionary
• business data objects
• risk management rules and procedures
• existing applications, middleware and security mechanisms employed
• user interfaces to IT services
• access control mechanisms in use
• the IT infrastructure (platforms, networks and their layout).

Here the following questions should be asked:

• Why should the specific logic be applied (procedures, conditions, rules)?
• What security-related data structures (business data models) should be included in the solution scope?
• How will the security mechanisms (encryption, access control, digital signatures) be applied?
• Who will be affected by the security mechanisms?
• Where will the security infrastructure be hosted (locations, layouts, communication links)?
• When will the specified security mechanisms be embedded into the processes?

Now let’s have a look at the existing environment and select the elements that will be re-used within the solution.

The component layer focuses on the assembly approach to ensure that all pieces fit nicely together and serve the purpose as expected. The logical and physical layers feed the gathered information into the component layer, which helps the business analyst learn:

• the IT products (business applications, servers, repositories)
• risk analysis, monitoring, recording and reporting tools
• protocols used to enable business processes
• user roles, their functions, actions and access permissions.

The questions to ask here are:

• What IT components (applications, servers, repositories) are in the solution’s scope?
• How will the specified IT components be used?
• Who will assemble the components (identities, roles, access control)?
• Where will the assembled components be located?
• When should the assembly process start?
• What is the time schedule for the solution to be assembled?

The final layer is security service management, which is concerned with ongoing maintenance of the solution and the embedded security mechanisms over the production use of the solution.

The answers obtained at this stage will facilitate the handover process at the end of the project. The questions to ask here are:

• What service delivery practices will be applied to ensure operational continuity?
• Why should these practices be in place (risk assessment, business continuity planning, risk monitoring and reporting)?
• How will security-related operations (user security administration, data backups, security monitoring, etc.) be carried out?
• Who will be responsible for account provisioning and user support management?
• Where will the security service management be executed (locations, sites, buildings)?
• When will the solution’s security service management be activated (security-related calendar or timetable)?

Added value to business analysis

When going through the layers discussed above, a business analyst will collaborate with architects, IT management, IT infrastructure practitioners and partners to ensure:

• the collected information is accurate and unambiguous
• policies and procedures are in place
• the existing IT landscape is known to the architects
• the existing components will be re-used to minimise solution costs and operational expenses
• the organisation’s requirements are translated unambiguously to partners to ensure trustworthy relationships.

Conclusion

The core function of business analysis is to transform business needs into requirements and ensure that a solution carries out its intended purpose. It is often not sufficient to gather the requirements to a solution to satisfy the explicitly stated business need, but it is easy to skip the requirements for business security by incorporating people, business process and data, premises where the business resides, and trustworthy relationships with business partners.

One more challenge in practice is that stakeholders think that technology covers all bases on its own, and it is hard to get buy-in from senior management of an organisation regarding the need for well-established and maintained information security.

The SABSA framework encourages business analysts to ask more questions to make the requirements clear and fully stated. This framework helps business analysts learn more about the organisations where they work and deliver extra value to these organisations.

Don’f forget to leave your comments below.