On the 16th of February, I have been invited by ATEA in Norway to speak about security.
During and after the session we will have the opportunity to examine and discuss the most important aspects to consider in security, especially on the business side.
Business is the most important aspect of any company, may people understand the role and importance of security in the business, but may not fully appreciate the complexity of implementing the necessary controls and strategy to provide all the protection required.
The session will provide invaluable advice and knowledge on the complex universe of security controls, concepts and best practices necessary to do business in today’s world.
We will look at key aspects to make your business secure, and consequently more effective and productive.
There are some very important pillars, in particular, a solid security architecture, which is a subset of architecture and implements an information security strategy. Like an onion, it is organised in layers of processes, solutions, and procedures, and they are all linked together across the company, strategically, tactically, and operationally.
Many companies and organizations approach security focusing on every single problem and area as if they are unconnected to the other problems, but in reality, they are all connected and linked together.
The usage of tools like the Sherwood Applied Business Security Architecture (SABSA) can drastically help a company to achieve that. SABSA helps the company to navigate across all these layers increasing the details in each one.
The same onion concept used in SABSA is used also in technologies like Microsoft Azure, where the very important CIA triad has been organised in several layers, a good reading is this article, Overview of the security pillar.
What I like about SABSA is the relationship between Business and Security is very well distributed between entities and business areas.
We need to use this schema following each layer and answering specific questions for each layer like Why are you doing it? who is involved? when are you doing it? and more.
There are also important aspects to consider as security policies and standards, they are often confused, I see companies writing policies as standards. The business objective should drive the creation of a policy and its implementation and enforcement and not vice-versa. Sometimes a policy is created without first looking at the business objective, and it creates the opposite effect, the policy will drive the business, and this is a huge mistake.
The standards are a natural consequence of the policy because a standard must describe the requirements that allow the company to meet the policy goal. for example, the standards are related to the specific hardware we need to use, users’ behaviours, which specific technologies are used or solutions implemented and etcetera.
Sometimes I see companies writing down policies describing technology usage or user behaviour, but these are standards and not policies, and this is exactly the case where, first the policy is not a policy, and also it can drastically drive the business objectives.
When we have policies and standards, then we can create and implement our procedures, a procedure describes the detailed step-by-step tasks to achieve our goal.
The most important rule here is never to create a procedure without the related policies and standards first.
All of the concepts will provide a good security baseline, this is another important aspect we will look at in the session. Sometimes, a security baseline is intended as a consolidated and proven security posture in the company, which is absolutely not.
A security baseline has two main scopes, first, the security baseline define is the minimum level of protection required, and second and most important, it refers to a point in time that is going to be used as a comparison for future changes.
Policies, standards, procedures and baselines can generate guidelines, sometimes I see guidelines used as standards, which is not exactly the meaning of guidelines.
A guideline is a recommended action, it is an operational guide for users, operations staff or IT staff. Usually, a guideline is intended to provide a way to achieve a specific standard.
All the security entities and areas are linked and related together, and it is important to follow the correct order in the implementation, this is also something we will discuss in practice in Norway.
Business is heavily dependent on security, and they must live together, in Norway we will examine how security can guarantee a successful business. During the event, we will also have the opportunity to spend time together and discuss many of these aspects in deep.
I want to thank ATEA for inviting me and for organizing this interesting event and opportunity. You can find all information about the event here
