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 (, 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 ;

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 — goes into details to specific requirements and guidelines or any discussion in regards to PCI DSS.