Classifying information is a basic requirement of any information security framework. This, of course, is sound logic. If you don’t know what the value of the information is, you will not be able to handle it appropriately. The problem is not in the requirement but in the way it is implemented...
The Websense security labs is out with its predictions for 2015. You can download them here:
Websense has made 8 predictions for this year. Please read the report for details. Here, I try to analyse them in the Indian context.
This post is in continuation to my previous post about the differences between ISO 27001:2005 and ISO 27001:2013. You check it out here. My quick and dirty analysis of the differences can be found here.
’Tis all a matter of context. One of the most prominent differences between the old standard (ISO 27001:2005) and the new standard (ISO 27001:2013) is the presence of ‘context’ in the new one. This context forces the implementor to focus on the question ‘Why are we doing this?’. In the old standard, one could not question the reason for doing an ISMS. We had to take it as a matter of faith and go straight to the task of defining the scope and the boundaries of the ISMS.
If you don’t have anything worthwhile to say, don’t say anything. (Could be one of the reasons why this blog has been silent for a while now…)
After infosec metrics became fashionable, a lot has been said about how to measure the effectiveness of your security program. ISO 27001:2013 made it worse - not only does it want you to measure the effectiveness of your security program, it also wants you to measure your information security objectives. With so many ideas and views and opinions floating around about what makes an effective security metric, I thought of writing a general guideline on how to identify what to measure in your organisation.
Have you implemented a firewall? An IPS? An AV? An IAM solution? A DLP? A DRM? An APT solution? A gateway proxy? An MDM solution? An SIEM? Chances are that you have answered “Yes” to at least two questions. (If not, please leave the information security industry right away and do something else. Really. Anything else will do!)
All these are very good technologies. They solve an information security problem, and they solve it well. What worries me, is that many (if not most) implementations of these technologies are not as effective as they can me. The problem? - Lack of well defined processes.
It is difficult to imagine a time without TrueCrypt. I do not even remember how I first got to know of TrueCrypt. I remember, however, moving the mouse randomly to create a new container. Young and foolish at that time, I thought it was a gimmick - not knowing that random number generation can be such a big pain. However, the software itself was great to use. Ever dependable. It had an element of mystery as well - the password for ‘duress’ where you could dump dummy data. It made you feel like a bit of a spy.
“Can you get us a security certificate in a week’s time?”
If you have been in the infosec consulting business long enough, you will, for sure, have come across this sentence. In this post, I want to vent my frustration and tell you the answers that I actually want to give - not the answers that I actually give!
The dust seems to be settling over the Heartbleed storm. Questions have been asked and answered. The experts and the newbies have voiced their opinions. This, I feel, is a good moment to answer those little questions that we have always been meaning to ask, but feared being thought of as stupid. Here is my attempt to explain Heartbleed in simple question and answer format. I have provided as many references as possible for further exploration. Feel free to suggest changes / corrections!
I generally write long and boring stuff about obscure standards and esoteric practices. Sometimes, I do get bored of this and want to write some fiction. I tried to be Sir Arthur Conan Doyle here. This post is my attempt at faking a news report!
TORA BORA: An infamous terrorist outfit has decided to implement and get certified on ISO 27001:2013 as information related to critical projects it undertakes keep getting leaked to outsiders.
When the ISO 27001:2013 was released, I did a quick write up about it here. Now that I have had some time to spend with the standard (get to know it better!), I am writing a more detailed comparison. This comparison will follow the typical comparison that I did for the BS25999 vs. ISO 22301. You can read about it starting from here.