O-ISM3 SECBOK is an Information Security Management System implementation template based on the O-ISM3 standard. It assists the creation of ISMS for organisations of any size, environment, and with any availability of resources Buy now your copy of O-ISM3 SECBOK and take your ISMS to new heights!
The O-ISM3 Test presents you with a Use Case scenario. The Use Case is a fictional travel agency in Madrid, Spain. Your role is to act as information security consultant who is preparing a meeting where you have to determine what are the information security needs of the Travel Agency.
The current state of affairs is that most information security professionals use the concepts of Confidentiality, Integrity and Availability for audits, consulting projects, risk assessment and management, and development of new standards. These concepts present a series of problems that have yet to be solved. The use of ambiguous, incomplete, not operational concepts without units of measurement has created a number of problems for information security management. Communication with between specialists and non-specialists in information security is difficult. Demonstrating the value of information security is difficult. Generally speaking, the use of these proxy concepts that don't add value makes information security management more difficult that it needs to be. Time is wasted, security projects that need funding don't get it, and trendy projects with little return get the green light. Luckily, change is possible.
The O-ISM3 Test pits the CIA triad versus O-ISM3 security objectives. In order to pass the O-ISM3 Test you have to solve the Use Case. You have two options: using traditional concepts like Confidentiality, Integrity, Availability (CIA triad option), or new concepts like O-ISM3’s security objectives. (OISM3 option). The options are mutually exclusive.
Determining the security needs of the Use Case will enable the you (the consultant) to determine the reasonable security measures to be applied, which are likely to be different, and cheaper, than all the security measures that could be taken. In order to prove that they can successfully determine the security needs, you have to create a meeting Agenda with a list of Questions to ask the managers or employees of the client company. This should be, in principle, easy since ALL THE ANSWERS PART OF THE USE CASE ARE AVAILABLE.
You have a choice to make:
- CIA Option: Questions can ONLY ask about Confidentiality, Integrity and Availability. NOT using at least one of these terms (or Confidential, Integer, Available) in any question results in a FAIL.
- O-ISM3 Option : Questions can NOT ask about Confidentiality, Integrity or Availability. Using ANY of these terms in any question will result in a FAIL.
For a question to be valid it should render naturally the answers given, for someone with intimate knowledge of the Use Case.
Since 13/4/2017 when the O-ISM3 was originally published, no one has ever passed this test using the CIA Option. if you think you did, please post online your list of questions and let me know via Twitter. You think you can? Download the O-ISM3 Test here.
Please note that there is a difference between finding out what the Travel Agency needs and what the Travel Agency might do regarding information security. If we were to compare the security practices of the Travel Agency with some standard, we could find out that the Travel Agency is not doing everything that a standard says can be done. There is a difference between doing everything that is standards state is possible, and everything that meets the needs of the business.
To learn more of why the O-ISM3 Test is important, check my lecture on Measuring Security.
These are symptoms that you need O-ISM3 SECBOK because your ISMS is failing:
- When certain people go on leave or get sick, performance is affected.
- Audits are painful and it takes a significant effort to pass successfully.
- Changes in the ways things are done are difficult and slow to implement.
- The same errors are made over and over again.
- More than 20% of the time of the team is used trying to determine what to do or how to do it.
- It is no infrequent to enter discussions with other teams about who is responsible for what.
- The available Metrics do not reflect the performance of the team or the level of security.
- Magic bullets are tried by management on a monthly basis and forgotten shortly after.
- New workflow software was supposed to solve all management issues. Instead, it has introduced issues of its own.
- Your ISMS is certified, but you are conscious that this wouldn't prevent a serious incident from happening.
If you have any of this symptoms, I would love to show you how O-ISM3 SECBOK could help you getting rid of all of them...
I knew it. It is too late to say now, but I knew a ramsonware worm attack was going to happen. Really. And I feel so bad about not writing about that I need to make a forecasts of other things to come in the world of malware attacks. I am sure I was not the only one who knew.
No, the recent WannaCry attack was not the largest infection in history. Conficker, Slammer, ILoveYou, infected more computers and perhaps created more damage. Why did WannaCry had to happen? Because it could.
We have seen for the last few years ramsonware distributed using phishing and drive-by downloads. It was just a question of time before someone connected the dots and thought of creating a ransomware worm.
Many have learnt now something that had been forgotten: Vulnerabilities need to be patched. As the consequences of not patching are not immediately apparent, and the consequences of not testing the restore of backed up data is not immediately apparent, for many IT teams it became acceptable not to patch and not to test. For the next few months, this will no longer be the case. After that, managers will have new worries, or will follow new fads, IT personnel will move onto new jobs, and in two or three years a new worm will shake the world.
Just as IT learn how to prevent worm attacks. attackers will learn about their mistakes. WannaCry writers made several mistakes:
- The infection spread to companies that were not the original target.
- The infection spread too fast: This attracted attention and the response was relatively fast and effective.
- There was a bug in the code that was supposed to prevent the code from being sandboxed and analyzed. It was used, albeit unintentionally, as a kill switch for additional infections.
- The number of bitcoin accounts was tool low to track who makes and individual payment. This clearly indicates that they where not aiming for multiple targets.
The interest of the ransomware attackers is that the infection is discovered quickly after some useful data has been encrypted, but not before. It is in their best interest that the ransom claimed is low enough to entice payment, and creating a sense of urgency by adding a time limit for the payment. It is in their interest that antivirus measures don't detect them, and that a system being patched or not does not stop the attack. How will they achieve their goals?
- Future ransomware attacks will trigger out of business hours instead of upon infection. As the data is not being actively used, the amount of data encrypted will be larger.
- Future ransomware worms will spread using multiple channels: Mail, Bluetooth, LAN, drive-by downloads, social networks.
- Future ransomware will target narrower and narrower targets more and more accurately, exploiting known vulnerabilities that have not been patched according to information collected by "malware scouts".
- Future ransomware will stop encrypting data. Instead, file names and contents, and specially database contents will be subtly changed over several days. This will render useless to have of backup copies, and will diminish the trust on the information so much that payment will be inevitable. Remember that data encryption is only used in order to prevent access to the data. Destroying the TRUST in the data will be even more damaging.
I would not be surprised if the change log is recorded encrypted in a blockchain based legger.
What gives data value is the cost of data acquisition, storage and processing, the quality of the data (In what degree can you trust it?). Young data is of relatively little value if it can be acquired again. Very old data may have become obsolete. Business quality data can be very expensive to replicate or validate. This is where the future ransomware will hit. Among all data types, dates are particularly vulnerable, as you can change them without losing credibility. Think of the damage of not knowing if the contract renewal of your clients is correct or not. What about the appointment of all your patients?
Inevitably, when this attack becomes common, companies will get ransom claims when no data has been changed. Will this be called bluffware?
And finally, attackers may stop using bitcoin. They may move on the stock market and demand the attack to the published, trusting to profit from the predictable changes in the stock value because of the company being in the news.
What can you do to prevent being a victim of this future ransomware?
- Implement highly mature security processes that stay in place after changes in management or personnel.
- Educate your users.
- Keep backup copies. Check periodically that restores work.
- Keep your systems up to date with security patches.
- Keep your systems protected with updated antivirus.
- Monitor that all changes in your business grade data are monitor and logged.
I sincerely think that this is the future of ransomware, but as a professional, I hope this time I am wrong.
You can subscribe to updates in this blog at the bottom of this page
There is plenty of published info about Wannacry; I am not replicating any here. How can your company avoid being hit? It is simple and it is complicated. First we need to understand why companies don't apply patches:
- They don't know it should be done.
- They feel they are too busy to do it.
- They feel it creates issues, with no obvious benefit.
- They don't do it often enough.
- There are no immediate drawbacks of stopping to patch, eventually it becomes normal not to do it.
- The people responsible to do it move on to new jobs, and the new ones don't get promotions or are rewarded for doing it. Why bother?
Preventing worms is a team effort between the Systems teams and Security teams. Security teams are responsible for monitoring new vulnerabilities and patches, and handing over that information to the System team.
(From Wikipedia): Conficker, also known as Downup, Downadup and Kido, is a computer worm targeting the Microsoft Windows operating system that was first detected in November 2008. It uses flaws in Windows OS software and dictionary attacks on administrator passwords to propagate while forming a botnet, and has been unusually difficult to counter because of its combined use of many advanced malware techniques. The Conficker worm infected millions of computers including government, business and home computers in over 190 countries, making it the largest known computer worm infection since 2003
The Systems team applied patches in periodic batches, for servers and workstations. It is the only reasonable way to do it in a large state. What lazy Security teams do is to forward everything immediately to Systems, and shift the blame to them if the patches are not applied. This is the Cry Wolf approach. We forwarded nothing. We just requested the inclusion in the next batch of security patches with one exception. Remote executable vulnerabilities affecting the most used OS in the bank.
We requested once or twice a year urgent application of patches. As we did not request it often, the Systems team listened to us when we did. When the patch that prevented Conficker came along, we asked for it to be applied immediately. And it was.
Bankia was never affected by Conficker. This did not make the news.
Patching should be done. And it should be boring.
Avoid getting your organization in the news. Find a way to collaborate with your Systems team.