Mind the Burnout Security Appliance.

Imagine this, as a Qualified Security Assessor, below is close resemblance of typical year scheduler for conducting assessment

  • January – March Service Provider Assessment (25 days)
  • April – May : Data Centre Assessment (15 days)
  • May – October: Retail Supermarket Assessment (60 days)
  • November – December: Service Provider Assessment (25 days)

A typical assessment average between 10 days to 100 days.

For the days that you are on the bench, these are typically compensated with 5 to 10 days short engagement such as conducting one of the below:

  • PCI scoping exercise
  • PCI Gap Analysis
  • Define a PCI Program for a client
  • SAQ assessment
  • ISO 27001 Scoping / Gap Analysis or Internal Audit. .

With this busy schedule, a consultant usual end up meeting or far exceeding the utilisation target, which for most consultancy is set to either 65% or 85%, in plain english it means out of 20 working days, you end up do all the 20 days.

In the security industry or at least from my personal experience, security consultants put in a lot of hours days in and out, which in the long run benefits the company as well as personal career growth, but what we fail to take into consideration, how you manage yourself physically and emotionally, so to minimise the burnout.

In order to minimise the burnout, it is important to make sure you have the right work/life balance. Whilst this is easy said that done, you have to create your own program (dont wait for the company do to this for yourself), where you make sure you have the time to exercise and engage yourself to do something outside of the cyber world.

For myself, I have manage to create a schedule where I can do physical activities during the week e.g. running, swimming, playing basketball and cycling. I also tend to read something outside of the cyber security world, which at least put my mind at easy, and mostly important my weekends are purely reserved for my family, during which I don’t check work emails or work on any report or sale pitch preparation. The trick, is to start small with a few routines, e.g. 10 mins walk/ running during lunch time and build from there. In order to perform higher and stay sharp, remember to take care well of your body and mind, DON’T BE A SECURITY BURNOUT APPLIANCE.

Move me to the cloud, so I don't have to take care of security!

I love the cloud, I guess you do as well if you heard that security in the cloud is automated! That is very bold claim and might be a bit misleading. In the past couple of years, cloud adoption have been a cool trend, and very economical for businesses in saving money when comes to running IT infrastructure (may be we should do another post on the reality of cost saving of cloud vs on-premises). While cost saving is one of the main drivers, it should be noted there are other drivers such as fast way of go to market, testing new ideas, being able to expand or reduce (elasticity) of the resources on a will, and also security being the other big factor.

One thing to be clear here, cloud security is a shared model, which is embraced by all the big Cloud Security Providers (CSP) such as Amazon, Microsoft and Google just to name a few. What this means is, the CSP provide security for the cloud physical infrastructure e.g. data centre, hypervisors, networking tools, and the customer is responsible for the data. This is the simplest view, however it is more complicated to this depends on the deployment model such as IaaS, PaaS, SaaS or other Cloud-As-Service (see diagrams below). Hence the famous phrase “CSP will be providing security of the cloud and the customer will be providing security in the cloud”.

Organisations should understand these differences in terms of their core responsibilities when comes to the managing security in the cloud. The model below from AWS, illustrates this more clearly and the logical step is for organisation to map these responsibilities to the right roles/people within the organisation.

Image result for cloud shared responsibility model
Source: AWS – https://aws.amazon.com/compliance/shared-responsibility-model/
Image result for cloud shared responsibility model
Source: https://www.synopsys.com/blogs/software-security/shared-responsibility-model-cloud-security/

So the next time you hear, let’s move to the cloud, security is automated and taken care for us, remember it is a shared responsibility and you have large part to play as well, at the end the data is yours, YOUR RESPONSIBLE!

Do you have a business security architecture? Yes we do! Here is our network diagram

Over the years, as a security consultant or as an auditor or security assessors, I have assessed or helped more than 50 unique businesses span from Europe, East Africa, to New Zealand, I can certainly say that at least 80% of these organisation do not have a documented business security architecture!!!

You may ask what is the business security archicture? how does it look like? is a Information Security Policy not a business security architecture? what about the Cyber Security Strategy? by simple definition according to (https://www.oxfordlearnersdictionaries.com/definition/english/architecture) architecture can be defined as follows

  1. The art or practice of designing and constructing buildings.
  2. the complex or carefully designed structure of something.
  3. (computing) the design and structure of a computer system and
  4. ISO/IEC 42010:2007 defines “architecture” as: “The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.” 
  5. In TOGAF, “architecture” has two meanings depending upon the context:
    • A formal description of a system, or a detailed plan of the system at component level to guide its implementation.
    • The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time

(http://www.togaf.info/togaf9/chap02.html)

6. According to SABSA , business security architecture is …

In my view putting all these definitions in context, an organisation will need to have a security architecture so that they have solid foundation of security that is align with business objectives and capability to piece together different components of security programs such as policies, technologies and other security controls. It has to be noted you can not build a house on shaky beach sand foundation as this will lead to unstable house with likelihood to crumple to pieces sometimes in the future. Same stance, should be adopted when build security programs that are based on well-designed business security architecture.

From security point of view, having a well designed and documented security architecture, in future will help to alleviate problems such as have to add on security solutions just for the sake of having a shiny appliance without realising what protection it provides for the business.

Whilst by default most organisations don’t have documented business security architecture, I would say it is not too late to start now, as you will find out you have already doing about 50% to 70% of what is required, why don’t you finishing piecing the pieces together to make that 100%? and don’t forget to document it.