:::: MENU ::::
Monthly Archives: July 2017

Please don’t kill your CISO if he doesn’t know how a virus works

I came across this rant (with the usual don’t-kill-me-am-just-making-a-random-statement-and-fully-intend-to-get-away-with-it disclaimer) on LinkedIn about how CISO’s are clueless about how a virus works, even with CISA/CISM and a decade’s experience under their belt. It got me seething about how this statement is wrong on so many levels, but then I decided to marshal it in a better way and keyboard-and-mouse my thoughts (penning my thoughts would have sound a bit cliched, anyway) in a bit more structured way. I could be wrong but am willing to learn from feedback and remarks of my readers (if there are any. I am a realist).

A disclaimer first – I am not trying to promote anything here except my viewpoint.

CISO is 90% management, 10% technical post.

Let’s look at this line of thought.

Management, IMHO, is about making decisions without complete data at hand. This means that entire organization has to be put into an abstraction (nothing else will give a high level view that quickly). However, it results in a whole lot of jugglery and political skulduggery which has given a bad name to management. In an ideal world, every management guy has hands-on experience in everything that his company is doing. However, reality is different. Hence companies look for an ideal combination of practical know-how and management skills, with mixed results. Just like it is difficult for a management guy to learn technology, it is also difficult for a techie to learn management skills.

Companies seldom fail because of lack of technology. They fail due to lack of management / business sense and leadership (market disruptions notwithstanding) . It took a Steve Jobs to make Apple where it is now. It took Bill Gates’ decision making and management skills to make Microsoft where it is today.

Time for another disclaimer now.

I am not saying that Technology or techies are not needed. I am only saying that Management is also needed.

Time to look at an image that I created to illustrate my point. What I am trying to put here is the viewpoints of different roles in the information security food chain and an example of the viewpoint in action. See how abstraction builds up as roles get near to business.











As per Rafeeq Rehman (someone whom I admire a lot), below are the different activities that a CISO has to perform these days (http://rafeeqrehman.com/wp-content/uploads/2016/10/CISO_Job_v8_A0.pdf). You will notice that a lot of those activities are leadership activities and not technical. Although, technical knowledge is required, it is at an enabler level (in other words, understand what your team is saying so that you can make a decision), because CISO is essentially a decision maker / leader, sometimes a manager (if the company is small, CISO may also end up doing a bit of technical work himself). And, folks believe me when I say it – IT IS A FULL-TIME JOB.

Does a CISO need to know how a virus works? That is not the right question. The right question is –

Does a CISO need to know how a virus works in the same way as that of an incident responder under his team?

The answer is a resounding NO.

If you bring an OSCP (without the business experience) for CISO , you will suffer. And if you bring a CISA / CISM (without the necessary incident handling experience) for leading a team of incident handlers, my condolences.

CISA / CISM are technical certs, but not in the way you think.

Let me approach it in a different way.

I consider, anything that belongs to the know-how of the field, technical. So, detailed procedures on how to audit is technical stuff (related to audit). Its usage of software tools may be confined to MS Excel and Access, but it is still technical because it describes the innards of the field (e.g., how to sample, what is the meaning of audit, how is it different than assessment, how to do audit, etc.).

CISA (Certified Information System Auditors) is for auditors (present and wannabes) who audit information systems (security is a part of it). CISM (Certified Information Security Managers) is for managers (current and wannabes) who manage information security management systems. Together, they have a knowledge base that, if internalized, can help a person gain lot more insight into the field than without. That doesn’t mean everyone can stomach it. No so-called-techie can read CoBIT without falling asleep (that doesn’t mean that you claim yourself a techie just because you can’t stand CoBIT documentation), but a decision maker will immediately feel home with that documentation because it offers him a vantage point for the entire information security control landscape of an organization. Not just that, it will give him enough ammunition to oversee an existing information security system. Because the decision maker is used to see things in abstraction.

However, this also doesn’t mean that everyone who is a CISA / CISM has internalized all the knowledge that was part of the syllabus (you didn’t think I am vouching for incompetent guys, did you?). Which brings me to the next part.

Certifications are not knowledge pills, you still have to work your grey cells.

Having certifications only mean that you have cleared an exam. It doesn’t mean that you still retain, cross-reference, update, and internalize all that knowledge that was part of the syllabus, after the exam and in subsequent years. It also means that you still have to be interviewed for all those above verbs and your suitability to the role. I will stop here because this topic has been beaten so many times that it doesn’t make sense anymore to trample on the same. Just google “are information security certifications necessary” to know what I mean. Having a certification is no guarantee of job-material in this field.

Standards and Compliance are not bad things, neither are they cause of the current sad state of affairs. People are.

As far as I am concerned, all of our problems stem from increase in population. But that is for another post. Let’s focus on the current point.

Bruce Schneier made an interesting point in one of his books (I think it was “secrets and lies” but I am not sure) that firewalls got famous NOT because they were technically sound and made perfect sense, but because their absence was getting flagged as non-compliance by auditors! And you thought your CCIE made all the efforts!

With all the jokes running around compliance and ISO 27K1, I still think that the flaw is in the implementation, not in the spirit.

Security has so many facets these days that it is a full time job just to keep all the balls in air and make sure that they don’t crash. Add to it the daily pressure of selling security to top echelons so that you can keep your job lest a non-clued security director, or some other high title, decides that he doesn’t need you with all the flashy tools in place (SIEM / DLP / IDAM, once installed, must learn on its own) and you will sympathize with all the CISO’s since the term infosec was coined. Jokes apart, management needs someone who can translate the jargonic (wait, is that even a word?) aspects of security into a more manageable chunk so that they can decide where to direct the funding and oversight (in other words, tell me if it is working for business and show me how). Standards (like ISO 27001) and compliance / regulations are supposed to help a decision maker understand security in a language that they understand. But, as Ian Tibble points out so poignantly in his book “Security De-engineering”, excel masters took over and they took the whole focus away. And we have been cursing management ever since!

In other words (meaning I could have avoided all this rant and said these lines instead and still made my point): –

Security management and tech must co-exist to create a beautiful recipe that is tasteful to the business. Singular won’t work.

I published this on both LinkedIn, Peerlyst and on my Medium Publication, Trinetra

Ajin Abraham’s Interview

I recently published another interview with a security star whom i admire on my medium publication, Trinetra. Please find it below.


Infosec has always fascinated me. After i wake up from my occasional slumber, i always look around to see if i can identify someone to admire (maybe it is the hero-worshipper in me). Off late, i have focussed on identifying people whom i like in infosec. I, then, pester them till they agree to give me an interview. I then post them questions over email, and they, well, respond over email. That’s how it works.

Today’s interview is with @ajinabraham.

I like Ajin Abraham because he hasn’t wasted much of his time in identifying his field of choice. Maybe that is the reason his body of work is so impressive (and he is young, so he has time on his side as well). So, without further ado, let’s talk to Ajin.

1. What is your online handle / real name (depending on your preferences)?

My online handles are ajinabraham or xboz in the dark past :).

2. What do you do for a living (company name not required, role / nature of work is preferred)

I am freelance security engineer, I do security engineering that includes developing security tools, security algorithms, pentesting mobile and web apps, code reviews etc. Apart form these I do applied security research and publish the outcomes at multiple security conferences. Also, I run an e-learning platform called OpSecX for security education and once in a while I do hands on live security trainings at security conferences.

3. Can you describe your journey in application security so far?

During school days, I was always curious on how games, software and os works. A teacher at school understood my fascination with computers and she taught me VB.NET. Unlike many others, I never started in C/C++ but instead in VB.NETand Microsoft Frontpage. I feel good about that now. At that age, everyone found C very boring and primitive. .NET and Frontpage offered great GUI experience and you could build a real application than printing fibonacci series.
It was applied programming that allowed me to create things that I imagine with ease. I could have never done anything better with C at that time and understand the beauty of application development if it was not for .NET. Eventually my curious mind took me to the internals of the applications where I started with reversing to understand the inner workings. The more I understand how applications work, the more I was able to use them in ways they are not intended to work. Later with the help of Google and StackOverflow, I learnt a great deal of things in Security and Engineering. I wrote security tools and published my research in the 2nd year of my Bachelors. Over years I found that there is a career that is in align with my passion and later got hired as an Application Security Engineer during the final year of B.Tech.

4. What were the challenges in your journey & how did you overcome them?

Today there are active community and security folks to guide someone in the security field. It was not like that when I started. The only help I had was Google and later StackOverflow. It was difficult for me to understand the concepts as I directly jumped into something before grabbing the fundamentals. Over time and experience I learned that I have to make my basics strong and clear. Thats when I started to learn everything from the fundamentals. It helped me a lot to understand things in depth.

5. What are the most important things that you want to focus on in coming years?

* Travel and explore the world and cultures.

* I am a petrol head, I love any thing that revs. More Drives and Rides.

* Keep my security knowledge updated. This is a rapidly changing field.

* Write more open source security tools, maintain the existing ones

* Do more application security research.

* Share what I have learned through trainings.

6. What, in your opinion, will be most in-demand things from an application security standpoint?

Skilled personal. We have everything in large quantity but the quality is not that great. Even though I am not a fan of AI, it seems like Machine Learning and AI promises a lot of advancements in this field. But we need skilled persons to implement this at the first place. In India, Application Security is always viewed from a Job perspective and most people doesn’t give importance to Applied Research and the Academics side of it.

7. What, in your opinion, should the industry focus on?

Hire people based on skills over years of experience and certifications. Also make opportunities to build up quality resource over quantity. Promote application security research and develop that culture right from college or school.

8. Where do you see the application security industry heading to?

Application Security is fairly new compared to other branches of Security domain. I don’t know what we will have in the coming future but as more and more things move to cloud, we need solutions to defend them. Eventually we will have huge data sets which will definitely help the machine learning solutions to perform better with higher accuracy. I am also excited as you are, lets wait and watch.

9. How can one become an expert in your field (not security in general, but the work that you are doing currently)?

Rule 1: Passion or Interest is what keep you forward. (Don’t start if you don’t have it)
Rule 2: Give it Time and Patience
Rule 3: Always start with the fundamentals
Rule 4. Always learn, unlearn and relearn

10. Do you think bug bounties help?

I don’t personally like bug bounties as for me I found it a waste of time.

But it has couple of sides.

The good thing is it helps companies to save a lot on their budget for security, spend less but get applications tested by a large crowd.

For the participants it’s a good way to make money.

In the security industry, there is a new bread who claim themselves as bug hunters/ security researchers/ experts by finding few low hanging vulnerabilities in web applications. Some of them doest even know how applications work. They don’t even know how the vulnerability occurs, how to fix it or how to report it professionally. Some of the bug bounty reports are hilarious (http://bugbounty.fail/).

I really admire and appreciate those 1% bug hunters who do real nice job, the guys who know their stuff. But others are pure disgrace to the industry. I am sorry to say it, but that’s the truth. This is what google says about their bug bounty program “Approximately 90% of the submissions we receive through our vulnerability reporting form are ultimately deemed to have little or no practical significance to product security,”.

11. What is your vulnerability disclosure policy (ignore if not applicable)?

I use to do aggressive full disclosures in the past but currently follows a 30 days disclosure policy with few exceptions.

12. In the wake of PRISM, and other monitoring activities that are taking place, do you think Internet usage will decline? Reasons?

I don’t think the usage will decline. The interesting fact is, most Indians don’t really care about Personally Identifiable Information (PII). I haven’t seen that culture of defending privacy in India much.

13. What, apart from your regular work, are you doing in the field of information security (any open source work, tool, etc.)?

I do a lot of open source work, you can find it here: https://github.com/ajinabraham
Also I occasionally blogs about my research outcomes here: 

14. What do you advice the newcomers who want to hop on to the information security bandwagon?

Start form the basics and fundamentals, learn how things work.

Always try to learn things by self. Ask only when you are really stuck. There is a great difference in learning and understanding by self and some one explaining it to you.
Use Google and StackOverflow.
Explore for there is no limits.

Process Myths, Busted

This article has originally been published by me on LinkedIn.


Disclaimer:- All of what is written here is my own opinion. ‘nuf said.

Raise your hands if you have heard / said these lines before:-

  • “This is not our job, this is the job of documentation team”
  • “I’ve many important things to do and deliver, I don’t have time for process”
  • “Process, what is this? We are doing fine here without it, we don’t need process here”.

This term ought to take the cake for oft abused / misused one apart from “housewife” (that is the MOST abused term on this planet IMHO. I think they deserve a LOT more respect than they get, but i digress).

I also think that knowledge of process is an evolutionary primitive to move up the corporate ladder because nothing provides a better view of the corporate than process.

This post is an attempt to explain the term from my perspective. Suggestions, remarks, feedback are welcome.

MYTH #1 – Process means documentation

Process is a way of doing things.

That’s it.

That’s what process is – A way of doing things. Say this again, and again and again, till your mind hurts and you cannot think further.

If you are following some steps to achieve an aim and if you are following a path (Ok, any path, your path, my path, some path) you are following a process (whether you like it or not). If you dream of reams of documentation in your sleep with reference to process, then I am sorry because it was never meant to be thought of in such a way.

Let’s pick some very common processes:-

  1. The process of going from one place to another
  2. The process of translating requirements into working software
  3. The process of capturing requirements from client;
  4. The process of eating / sleeping / buying things / selling things ….. you get the drift.

Just because it has not been documented, doesn’t make it a non-process.

MYTH #2 – It’s not process if it ain’t best practice

Now, this actually hurts. Best practices have a way of hurting like no one else. We have gotten results – good results, with satisfied customers – with less-than-best-practices. Also, has anyone seen a definition of it, lately?

Practically, if it works for your team, helps you repeat the success again and again, then I guess it is a best practice, for your team.

Ok, if you insist, call it a better practice. But please, don’t call it the best, because it depends on a lot of things (# of people required to execute it, can it scale up/down, efforts required to implement it, clear ROI, etc.).

MYTH #3 – If it works for company A, it will work for company B

Nothing can be farther from the truth.

The line, when corrected, would include “may” instead of “will”.

A successful process implementation answers the following questions:-

  1. Does it account for the existing capabilities of the team (in other words, can the existing team do it, with their current skill set)?
  2. Does it provide a way to not only repeat the success, but also to record the failures?
  3. Does it take the number of people into account (in other words, process that requires 200 may not work for 20 member team, and vice-versa)?

Successful processes depend a lot on the balance between other 2 factors – people and technology (and here i was thinking that it is just for feel-good factor and CYA, meh). Which means you will not be successful if:-

  1. Technology and process is appropriate but people with required skills are not put to implement the process;
  2. Technology and people are appropriate but the process is outdated (e.g., no review mechanism, no record keeping even though technology implemented supports it, etc.);
  3. Process and people match but no technology in place to help them (e.g., a very complicated, industry-recommended and proven process to handle incidents without tools to identify them in the first place, no-IDS, anyone?);

Please let me know if these myths exist or it is just a figment of my imagination. Any feedback is welcome.