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.

Another 2020 Cybersecurity Prediction.

I think it is that time of the year again when the security experts see the future and predict the present. I guess I should join the bandwagon, so can I have your attention please?

#1 Organisations will continue to be breached

It’s days away from 2020, and the rate of breaches are not likely to go down, organisations will still be breached, as much as I would love to believe that organisations are doing well protecting themselves, you will be surprised with how many organisations that cant even meet the minimum requirements that are set to comply with NCSC top 10 steps to cybersecurity (https://www.ncsc.gov.uk/collection/10-steps-to-cyber-security), simple questions is your patch management program integrated with your vulnerability management process that cover that unpatched windows 2003 server? sorry I meant windows 2008?

#2 Increase spending in cyber security budget otherwise you will be breached

Increase budget in cybersecurity program is a good thing, but spending the money only in buying security appliances without first establishing ‘what assets’ need protecting is not a good move. Organisation should ensure that the security objectives are aligned with the business objectives, and establishing this is should be systematically done through documenting a business security architecture. So security execs (CISO/CSOs) should be able to trace back when they are asked why do we need to invest in ‘dark web monitoring service’ or ‘shiny security appliance’?

#3 Your applications are still vulnerable to OWASP Top 10 (of 2013)

A number of web apps are still vulnerable to the 2013 version of OWASP Top 10, and if you see any of the below during your testing, I guess you need to have a word with your dev team, should we say DevOps or DevSecOps? whatever the name, this means there is something wrong with the development practise and whole lifecycle.

  • A1 Injection
  • A2 Broken Authentication and Session Management
  • A3 Cross-Site Scripting (XSS)
  • A4 Insecure Direct Object References
  • A5 Security Misconfiguration
  • A6 Sensitive Data Exposure
  • A7 Missing Function Level Access Control
  • A8 Cross-Site Request Forgery (CSRF)
  • A9 Using Components with Known Vulnerabilities
  • A10 Unvalidated Redirects and Forwards

#4 Your Incident Response Plan have been table-top tested for the past 3 years, the real storm comes this January.

I have seen organisations end up doing only table top exercises in order to tick compliance tickboxes, while one may argue that invoking the full IRP may be costly, but it may cost you more, if the only test for the past 3 years you have done are just table top exercises.

Real-life test maybe needed to mimic if the actual disaster happen or data breach happen? Maybe a question to ask yourself, how is that public relation department prepared? do you have one? do you have a forensic expert internally or do you need to have external experts comes in? do you have a retainer arrangement in place? they may be busy!

#5 My people are security trained at least once a year

Most organisations now have information security trainings, that happens at least once in a year. As you know, this involve sitting down in front of the computer go through slide decks, or CBT , with an exam to complete at the end or maybe a coupe of policies to read. Whilst these are good practises, organisations should aim to conduct social engineering tests on frequent basis to test how well their human security defense is effective.

To be continued …

Data is the queen, so understand how to protect your data

How much do you think data is worthy of companies such as Google or Facebook? You might be surprised, according to a Netflix documentary the Great Hack, Data for these companies is worth more than the price of oil! The question is how valuable is your data?

In this modern age of big data and analytics, data is the queen, which should be protected securely. What I have found is before the enforcement of EU GDPR, in the context of personal data most organisations do not know where their data resides (data storage), how much they process (number of records), what type of data they process, which critical business processes that are processing the data, hence the question comes how can you protect your data?

In my view, first, everything starts with architecture, data architecture for this matter will drive everything in regards to people, processes, and technology from the data strategy, data protection strategy, and data breaches response plans. Do you have data architects? Do you use a data architecture framework such as DAMA, TOGAF? Maybe that’s the best resources to start at https://dama.org/ ; https://pubs.opengroup.org/architecture/togaf91-doc/arch/chap10.html

Secondly, organisations need to map the flow of the data from the time when the data enters the organisation, processed, go out of the organisation or if it requires to be disposed of securely. On all these processes, security should be embedded by design and not an afterthought.

Data as your queen needs to be protected all the time, the same way this applies in chess, the same way applies in the real life, the way monarchies are being protected over the centuries, use the same concept when protecting the organisation’s data that matter to you. All the best 🙂

Common mistakes made by QSA during the PCI assessments.

I have been a QSA for the past 6 years and before that I have been involved in managing PCI programs for more 3 years in the banking environment. So it is fair to say I have experience PCI from QSA ,and merchant/issuer point of view. During this time I have worked with a pool of QSAs and I have conducted a handful PCI assessment covering organisations in different industries including healthcare, retail, insurance, TV/media, government/public, mobile service providers and many more.

regardless of the complexity of the environment and payment channels, most of the organisations either service providers or merchant have fundamental technologies e.g. database, virtualisation, cloud computing, networking etc which should comply with the PCI DSS standard. So the QSA is expected to understands these technologies at least to the basic level i.e. understand how it works prior to go onsite and conduct the assessment, the reason being, is you understand the technology, processes and people that you are going to audit. Whilst this sounds common sense, you will be surprise how many QSAs do not take this into consideration. Below are the five common mistakes made by QSA.

(1) Dont understand the scope of the assessment

(2) No enough time allocate to conduct the assessment.

(3) Not understanding the underling technologies used by the audited organisation i.e merchant / service provider.

(4) Do understand the in-scope payment channel and the applicability of PCI requirements / eligibility as per SAQ.

(5) Do not follow the audit procedures on the PCI DSS reporting template.

I will expand on each of these mistakes one by one in the updated post. For now I would like to make you aware of a nice PCI blog by PCI Guru here — https://pciguru.wordpress.com/which goes into details to specific requirements and guidelines or any discussion in regards to PCI DSS.

Do you pentest your infrastructure? YES. Have you tested your people? Mmmh!

Most organisation have either regulatory / industry requirement to do penetration testing on annual basis or when significant change happen to their environment. Whilst this is consider a good practise, the coverage of the test usual include the technology infrastructure both externally and internally. The question remaining how many organisation test their own people?

In today world of beefy technological security solutions, penetrating the external perimeter (for traditional model) is very hard comparing to the previous years. This also apply the same to the cloud services. As the results, the attackers, have focused their attacks on people, who as you may know present the weakest link in the security chain such attacks including spear phishing etc.

Business understand this but regardless they have not invest in protecting people with security controls such as security awareness training , and targeted security training per job role e.g. CEO specific training, Bank Teller specific trainings. Failure to do so open doors for attackers.

So next time you do penetration test, ensure you include the people testing, and this can be social engineering test by specialised organisations. while these tests can be done once a year, the organisations are encourage to have internal tests done at least quarterly to keep human at very defensive mindset to understand that security attacks can happen anytime and they are the one targeted the most.

Incident Response Plan, when was last time you tested it?

Incident Response (IR) is the decision away from having your business go down under or resurface after a few hours.

Most organisations have IR shelved somewhere collecting dust. The IR is good to the extent to be shown to auditors for compliance tick box, however not to the extend to save the business when it comes the time to do so.

We have heard a lot of stories on the internet and front-pages of data breaches, the most prevalent theme is the difference between detection time and discovery time, that is the time when the incident actually happen(when the hacker breached your systems and resides in) and the time when the organisation when actually discovery the breach happen. Organisation takes long to detect the breaches and when they do, they can’t get their IR plan running as expected. This boils down due to the fact that the IR plan have not been tested on frequent basis (not annually :), this need to be more frequent than that).

IR coordination activities is not only to be managed by the cybersecurity department, the activities need to be organisation wide, this should include senior management (CxO officers), public relation, business units, IT and cybersecurity departments.

My 2cents, organisation need to to the below when comes to IR

– Draft IR plan which should include all the critical business unit

– The IR plan should have communication plan and assign the ultimate decision maker e.g. CEO, CIO or C-Level executive

– Test different scenarios e.g. state-sponsored attacks, physical attacks, insider attacks etc.

– Test more than twice a year (not table top exercise, actual war games)

– Improve your plan once tested, from the lesson learned.