Is programming knowledge required for web application penetration testing?

Not required at first, but you will need it to move up the ladder (in proficiency). Here’s why:-

  1. For DAST (Dynamic Application Security Testing), aka looking for security weaknesses when the application is running, understanding how a web application flows helps in identifying weaknesses in the coding. While you do NOT need to learn it at the same level as a programmer does, knowing it will enable you to look in the corners that other usually won’t look.
  2. A web application builds up (and runs on) lot of code (not written by the developer of the application). Those code packages (also called third party libraries, e.g., jQuery, Bootstrap, Laravel, Django, etc.) have been fortified by secure code, eradicating low hanging fruits (aka easily identifiable by script kiddies). These days, understanding nuances of a programming language helps a tester to (here i go again) look in the corners that others usually won’t look.
  3. If you are doing SAST (Static Application Security Test), aka source code security review, understanding the language is a definite requirement.

Do not kill your pentester for little or no value-add

Disclaimer: This would be a long post (culmination of many old posts) with lot of different opinions, thoughts. If weaving is not right, please provide feedback on how it could be corrected.

I had the good fortune of reading couple of threads by gentlemen whom I respect for their grounded advices. Their posts triggered some thoughts in me that I had jotted in few old posts. So i tried to weave them into one post.

The thoughts are my own and hence, may read slightly off the mark. This is NOT a scientific post, but my observations. You have been warned.

I have divided my thoughts into 3 buckets. They are

  1. Technology
  2. People
  3. Process


Penetration testing (or pentesting) is evolving along with technology. Earlier days of nmap-metasploit-jackpot are over (although I have a nagging feeling that this may not be case for every organization). Defense is becoming smarter (EDR, better firewalls). Although more buzzwords have entered the market (red-team, breach and attack simulation, intelligence based penetration test, etc.), the implementation has not yet reached the mass.


Assuming there is certain body of knowledge related to pentesting, there are two ways to achieve it — in a top-down manner or bottoms-up. The BoK doesn’t change, only the method of attaining it changes. The method depends on the way how your brain is wired to learn things.

High level pentesting BoK

Top-down guys always look at things from high level and then take each step down. For example, a top down guy who is tasked with learning pentesting will almost always start from outer perimeter of the BoK (the process of pentesting, different methodologies, types of pentest, high level execution methodology, etc. This type of thinking suits a person at a middle level to higher levels of management, because this thought process supports an abstraction based thinking. These are also the people who will, usually, collect their thoughts in a way so as to publish a book.

Now, you are asking for disaster if you ask a top-down person to:-

  • Perform a technical penetration test (I am not talking your nmap-metasploit type);
  • Explain why a particular nmap switch has to be used;
  • Learn things by reading a book that doesn’t have any hands-on element in it;
  • Argue the differences between different firewall evasion strategies, etc.

A bottom-up guy will always start with getting their hands dirty (running the tool rather than going through the man-page). Then, slowly, this person will start picking different tools, running them, then combining them in a script. Understanding each tool’s output, executing a full-blown engagement will come later. These are the people who amass lot of knowledge & wisdom over a period of time, but organizing it into a book — sorry! These people don’t have patience to read a book from cover to cover, let alone design and publish one.

Now, hard-core penetration testers usually are of the bottoms-up type. Which means you are asking for disaster if you ask them to:-

  • Prepare an executive summary that can be consumed by an executive / decision maker
  • Align their findings / vulnerabilities with any particular risk management standard (e.g., FAIR, ISO 27001, etc.)
  • Perform risk assessment.
  • Explain differences between CVSS v2 & v3

Another question that needs thought — where to use bug-bounty hunters and pentesters?

TLDR — use bug bounty hunters after you reach “unknown unknowns”. See the sub-section “timing has to be right” below for more details.


This is where I think we need to work our things out. To that extent, I agree with most of the points that were made here. Here’s my commentary on Greg’s observations: –

Scoping it right, but it gets left all the time

Pentesting is both an offensive and individual engagement. Setting the rules of engagement is one of the toughest things to get right. Both pentester (am I doing more for less?) and the customer (am I getting less for more?) grapple with it. While customer don’t want to get hacked, they don’t want to expose their systems to harsh testing because they have a fear that it will break. They just want pentester to inform them of any vulnerability without exploiting it so that they can close it. However, pentester often fail to communicate it properly that without trying to break, they won’t know if a vulnerability exists! It is one of those catch-22 situations that lives long after the engagement is over.

This issue leads to ambiguous language in contracts that becomes cause of lot of heart-break and half-assed outcomes from a pentest. However, it is mostly because the engagement was not thought through.

If you want more vulnerabilities to be identified, provide information to your penetration tester and allow them to break it to test it.

Check inside, not just outside

I agree with Greg here. Testing outside perimeter alone won’t help in understanding a company’s security posture. Internal pentest need to happen as well. It will help understand the impact of what happens when an internal credentials / system is compromised. There is a lot more information that gets accessible to an adversary once a working AD credential is compromised.

Timing has to be right

I think every company, from a security posture point of view, goes through these phases (based on a loose interpretation of the Johari Window ( –

Known Knowns (they know they have issues, and others do as well)

The companies in this segment know that they have to improve on their security posture a lot and understand the major areas to focus (knowing fully well that vulnerabilities must be present in a plenty). Further, they have issues in their external perimeter (leaked info, keys, access, etc.). Pentester’s wet dream. These companies should start with regular scanning of their infrastructure (outside in, i.e., outside perimeter first, then inside) with a focus towards internalizing patch management (infra, apps, especially third-party apps like Java, Adobe etc.). Don’t dream of getting a red-team / purple-team engagement. You won’t get as much benefit as you should as you won’t stretch those red-teamers.

Known Unknowns (they know they have issues, but others don’t know that yet)

Most of companies fall in this bucket. They have an understanding of critical assets that they should protect and have implemented controls in / around those assets. However, they are not sure if that could be all. Also, these issues mostly exist in the internal environment. These companies should have 1 red-team engagement covering outside perimeter (without phishing in scope), coupled with round the year internal pentesting.

Unknown Unknowns (neither they know that they have issues, nor others yet)

It could be most dangerous (if the company doesn’t have a single decision maker who thinks security should be at-least an agenda point in decision making meetings) or most mature state in a company’s life, depending on various factors.

  • If it is former, ISO 27001 (led by a good consultant) should be a good choice, as it will start the institutionalization of security processes from top-down. Good consultant is imperative as it will THE deciding factor between an excellent ISMS that delivers value & a botched up one. ISMS implementation is a favorite topic of mine, more on that later.
  • If it is latter, they should hire red-teamers & bug-bounty hunters with focus on one area per quarter (e.g., phishing, external firewall bypass, physical security, chaining multiple vulnerabilities to access key company data, etc.).

Needs to align with high level controls to give a sense of state of security

I have been saying this in my previous articles as well. There is value in both top down approach (governance, assurance, audit) & bottoms-up approach (regular housekeeping activities related to security). One cannot exist without another. Top down and bottom-up people need to meet halfway before deciding on the security assessment part. Imagine this (sort of ideal scenario):-

  • The CISO consults involves internal auditors to set the scope for the RFP towards getting a vendor for their yearly penetration testing;
  • The Internal auditors design a set of technical controls, mapped to the company’s security policy / procedures.
  • Internal auditors plan/schedule their internal process audits along with these penetration testing exercises;
  • The technical controls are provided to pentesters to test, along with the normal pentesting workflow;
  • The output of the pentest exercise (aka findings) are then mapped to company’s security procedures & the internal audit findings, to provide a holistic view of security status of the company.

— End of post —

External Network VAPT: tools, information sources

Photo by Sean Musil on Unsplash

This is a live post; it will undergo changes, which are captured in change log, provided at the end of this post.

Being part of many external VAPT engagements, one thing was clear from outset — methodology is the key, but so are the information sources & tools for conducting the VAPT.

This series is my attempt to record all the tools and information sources that have been helpful to me over the last few years.

Traditionally, external VAPT can be divided into the following major phases:-

External VAPT, Process Flow

In this article, we will try to cover the first 2 phases — basic pre-engagement & reconnaissance.

Basic Pre-Engagement

It is very tempting to start an external penetration test as soon as customer asks us to. After all, we can perform this test from our current location (no need to travel to customer’s site to perform test) and,

Who cares about that silly thing called documentation? Turns out, except us, everyone.

Your customer wants it so that they can compare, at the end of test, whether the entire perimeter has been accessed or not (in other words, did we leave anything out);

Your boss / management (any other role who is a decision maker in your hierarchy) wants it so that they know we didn’t do more than we were asked to (scope creep is not mythical) & that we did all that we were supposed to;

So, here are the things that one should keep in mind before starting an external penetration test

Scope of work

Is entire perimeter to be tested, or few IP addresses?

Few customers will share the list of external IP addresses to test and won’t be happy if you stray from that list. Few other customers would want you to tell them the attack surface (in other words, what IP addresses of ours are exposed publically) before they give us permission (for full or partial test).

Type of test (black box, grey box, white box)

Black box — we won’t tell you anything about our network, the type of machine under that IP, etc. We want to see what an external attacker would do.

Here, you will have to make it clear that uptime of external IPs are not your responsibility. You will need their IT staff to be on standby during the test so that they can monitor the network and devices for any performance hit. You will be expected to stop when they ask you to.

Grey-box — we will give you some information (e.g., IP address space, type of devices, make / model, etc.).

The expectation here, from customer, usually boils down to one line — now that we told you the things that we have on our external network (and potentially saved you lot of time), what vulnerabilities are we exposed to?

Is physical security testing part of scope?

If it is, i suggest you get your get-out-of-jail card before moving a muscle. Also called “authorization letter”, this document (signed by an authorized signatory — may or may not be the CISO / CIO but the person who is legally authorized to sign agreements on behalf of the company) will help you when you get caught in a mis-understanding with local cops. The coalfire incident has shown how important is this document. So get this before starting the pentest of any service / infrastructure that is business / mission — critical for your customer. TrustedSec has made a host of legal documentation available for no cost (thank you guys!) to facilitate legal boundaries around your physical security pentest. I recommend you have a look at them.

Few more pointers:-

Report Deadline

Very important. End of testing is different from end of engagement. Testing ends when it ends (!). However, reporting is another, separate activity. Reporting starts after testing is over. You must schedule some time for this.

Preferred timings of test

Some customer would want you to initiate the test when no one is in office (out of working hours). Few customers would ask you to initiate the test during working hours. You have to document this.


Wikipedia defines it as

Credit to Wikipedia

The third definition relates to the objective of network recon. There are 2 major ways to perform recon — one that makes a lot of noise, letting everyone know that you are onto them (active) while the other is more sneaky, stealthy (passive).

Passive Recon

Many people have written lot about it. However, i have few points to mention here:-

Whether you have IP address or a domain name, you need to find ASN (Autonomous System Number) belonging to that company first. The benefit — it will help you find all the IP ranges that belong to the company. You can use below links to find ASN from a domain name or IP address:-

You would also want to look at sub-domain enumeration. Utilize the following tools

  • Amass
  • Censys
  • Shodan
  • Spiderfoot
  • Virustotal
  • VHostScan (
  • Google Transparency Report (
  • CertSpotter
  • CertDB

Active Recon

This is where we interact directly with the customer infrastructure. The tools that could be utilized in this activity include, but are not limited to, the following:-

So that’s all for now. We will expand on this series soon.

How to download Nessus Pro using cURL…

assuming you have a valid account with tenable and have paid for your license.

Problem Statement

You are setting up a cloud server to conduct Nessus scans. You don’t have access to ssh (due to various reasons, let’s not go there). you are using cloud console. How would you download Tenable Nessus Pro on your cloud machine?

curl --request GET --url  --header “Authorization: Bearer <auth-code-here>” --output ./fileName.deb

How should a CISO deal with XSS?

I got many comments (thank you everyone, as i learnt a lot) for my article that i published some time back.

I realized that i need to explain my thoughts in a different way (as many people were of view that i am championing a person-with-no-technical-knowledge as CISO. In order to explain my thinking, let’s take a vulnerability like XSS and see how each role (from my previous article) should respond to it: –

  1. Security Analyst – He/she needs to showcase the PoC (Proof of Concept) of XSS, and not just share a text from OWASP website. In other words, the analyst needs to prove that the XSS (in this case) is exploitable, and how. We all know that not all XSS can be exploited, and market is already ripe with all those script kiddies who can just run some tools and email the report (after modifying the aesthetics).
  2. Security Manager– He/she needs to understand the impact to the application (e.g., what is the critical data here? Can it be lifted off because of this vulnerability? Can the system be taken over due to this vulnerability? Has it been proved here, with ample evidences so that i can take it to the CISO?)
  3. CISO — How important is this application to the company? Who are the customers for this application? Has the manager validated the vulnerability and the proof? Is it damaging our confidential data? What is being impacted here (C, I or A)? What else is affected here? Would it be possible to pivot to other important machines in our network after compromise of this system because of XSS? What are the other defense mechanisms in place to prevent a pivot? How much time will it take for this vulnerability to be patched? Would there be any downtime (during patch)? Can the customers of this application wait till the application is patched, tested, re-deployed? what can we do to expedite it (if it is so important to the company that downtime won’t be tolerated)?

After getting responses of all questions (in case of CISO performing role of manager, or vice-versa, he/she will have to ask both types of questions to the security analyst & to himself), he/she will have to decide the next course of action.

I, on my side, have seen critical application vulnerabilities & resulting risks being accepted during an engagement because no downtime could be afforded. Instead, in this case, the CISO (after discussing with the penetration tester) created an exploit video, demonstrating the impact. He then got a WAF (Web Application Firewall) deployed before the app (with new rules to handle the XSS, which were created by the penetration tester. He had gotten relevant clauses inserted in the PT engagement beforehand, predicting the shortage of resources and possible blockages by management) and used the video to increase management awareness. He got approval for the system upgrade, subject to the condition that the old copy will remain behind WAF till the new copy is developed and tested.

He was able to do all this because

1. He asked pertinent questions to understand the issue

2. He drove the penetration tester harder, asking for PoC, getting all relevant contractual clauses in place so that he gets the necessary support, etc.

3. He had a game plan in place to handle the vulnerabilities.

If i put understanding of XSS on a scale of 1–10, with

1 — knowledge of expansion of XSS

2 — understanding a visual representation of how XSS works (e.g., something on the lines of this URL

3 — Understanding the impact of XSS (either by pestering the penetration tester to prove it or going through online examples like this URL — OR–security-series-81)

4 — Ability to explain, with example of, XSS code (e.g., something like this URL —

5 — Ability to identify the vulnerability through automated tools (like burp or acunetix, etc.)

6 — Ability to identify the vulnerability without any tool (manually)

7–10 — Ability to understand XSS on a deeper technical level (ability to exploit XSS through various methods)

As you can see, steps 1–4 can be done by someone with basic knowledge of information security (and i am full advocate of a CISO having spent some time in this field. I don’t expect a newbie-in-infosec-but-a-veteran-in-management to succeed in this field). Script kiddies can handle the step #5, but you need a technical person to perform well between 6–10.

I am increasingly seeing this issue. One needs to understand how XSS works and its impact on that application and, as a consequence, the organization. One also need to understand the various defensive measures that are present in the industry. However, as a decision maker, your technical skills won’t save you if you do not have decision making skills. Decision making is a skill in itself that takes tremendous practice.

Process Myths, Busted

This article was published by me on LinkedIn earlier.

— — — — — — — — — — — — — — — — — — — — — — — — — –

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.

Please don’t kill your CISO for not knowing 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.

InfoSec FoodChain

As per Rafeeq Rehman (someone whom I admire a lot), below are the different activities that a CISO has to perform these days ( 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.

My Publications

Well, so far, i have not fared very well as far as content churn is concerned. Mostly because of my self-induced-coma-like-tamasic-laziness. My ancestors would have scoffed at it (maybe they already are. However, if my life is any indication, i think they are benevolent and merciful, like my parents. But i digress, again).

Here’s a partial list of things that i have published so far. Hoping to increase the quality in the times to come (Credit: Anton Chuvakin for inspiring the format): –

  1. Mar 2016, {ctrl+z} My Interview :: Here’s what is should have said (LinkedIn post); I have tried to re-capture the essence of an ISMS implementation through a-should-have-been version of an interview response that I gave long time ago.
  2. Mar 2015, ModSecurity — Manager’s Dilemma (un-edited version, published in march issue of OSFY); This article tries to explain why deploying WAF in general, and modsecurity in particular, makes sense for a manager.
  3. June 2014, Process Myths — busted (published as a post on LinkedIn); This post lists some of the customer impressions related to processes that i could gather and my response to those myths.
  4. Sep 2013, Importance of Maturity Models in ISMS (published in October issue of ClubHack magazine); This article discusses the importance of process and maturity models and their requirement for ISMS (Information Security Management System).
  5. Sep 2013, Why is host integrity monitoring important (published in October issue of OSFY); This article discussed the role of file integrity monitoring system in the present compliance and regulation landscape.
  6. Aug 2013, DSCI Security Framework for ISO 27001 Implementers (published in September issue of ClubHack magazine); This article discusses the DSCI Security Framework and its relevance for ISO 27001 implementers.

Interview of Akash Mahajan

My interview obsession started before Ajin Abraham. My first interview was with someone who defied quite a few stereotypes in making his mark on the india infosec scene.

Now, here’s is someone who started working in this field without fulfilling any checkpoint in a standard HR recruitment checklist. Yeah, no certification (Gods must be crazy!), However, he is famous not just for his involvement with NULL, Bengaluru (look ma, constitutionally correct pronunciation!) but also because he is an extraordinary presenter. The thing to look for is his style of presentation. The name – Akash Mahajan

So without much ado, here’s it.

ME — What is your online handle / real name (depending on your preferences)?

AM — Usually I use makash, in some places I use akashm. But mostly googling for Akash Mahajan will return most of the results about me.

ME — What do you do for a living?

AM — I help small and medium companies become secure. It starts with me supporting them in making their web apps, mobile apps secure, building internal app sec capability, usually extends to me making sure their servers and cloud networks are secure. Sometimes companies take my help in charting out long term strategy about their security choices. For a long time I worked as a freelancer in this field but since last year I registered as a private limited.

ME — Can you describe your journey?

AM — So I was on my way to becoming a java programmer. Not particularly a good one. While working on java related projects there was a massive network outage in my company. The internet was basically not working for a week because of malware outage. I wasn’t affected personally because I was using a linux box. When the infection reached the team subnet I was in my project lead allowed me to take a look. I was able to isolate the malware and remove it from the system fairly quickly. Once that was done, I shared my solution with the IT team and realized that I had a lot of fun doing this. Definitely more fun than writing java code. That is what started my infosec journey. I quit my job and joined a security products company. While working there learnt a lot about network security, application security, python scripting and virtual machine automation. One day in the month of June of 2008, I decided that I should try being a freelance security consultant for all the hundreds of companies in Bangalore.

ME — What were the challenges in your journey & how did you overcome them?

AM — I am not an engineer. Initially I never thought about going on my own. I got rejected by a bunch of companies for not being an engineer or not having a security certification. I got myself a Certified Ethical Hacker certification because companies started demanding it. Once I had a certification it was easier.

In our industry a bigger challenge is to keep yourself updated about latest security techniques etc. I did struggle with that a lot at the beginning. Then one day on twitter I posted about asking for security communities in India and Aseem responded. They had started null — The Open Security Community sometime back in Pune and were looking for people to grow it to other cities.

Having a community full of seriously talented people doing security day in and day out makes it far easier to know what is happening in this field. Not only that we have so many folks who are doing original research, so in some cases we get to see the newer stuff even before it becomes public.

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

AM — Building and taking null to every state in India. Build my company to doing high quality security research and offering testing services for various levels. Personally I would like to try adventure sports.

ME — What, in your opinion, will be most in-demand things from a security standpoint?

AM — Automation of security testing, deployments(devsecops), user data privacy and figuring out ways on how to trust 3rd party software and services.

ME — What, in your opinion, should the industry focus on?

AM — Industry as a whole needs to focus on building quality solutions. Also while profits are important industry should understand that in the knowledge economy a well trained work force is not only an asset but the returns from such a work force can be exponential.

ME — Where do you see the security industry heading to?

AM — More automation, instrumentation of solutions, deployments. Also more and more systems will be in the cloud.

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

AM — Practice, collaborate, publish, solicit feedback. Wash rinse repeat.

ME — Do you think bug bounties help?

AM — Bounties do help. At the very least bounties offer a short term incentive for more people to spend their quality time in finding bugs. And humans tend to love competition. The indirect benefits of bounties are that when more and more people starting bug hunting seriously they also get serious about collaboration, sharing of knowledge and it always helps when a group of people are focused towards a common objective.

ME — What is your vulnerability disclosure policy (ignore if not applicable)?

AM — I don’t disclose bugs.

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

AM — Internet usage will not decline. But yes it is possible that companies will spring up trying to get customers based on nationality etc. Governments tend to work towards exclusivity and sometimes inefficiencies get hidden due to the nature of how they operate. This will make sure that some parts of the world will be working with substandard software which if taken positively can mean better competition or a clear competitive disadvantage.

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

AM — Nothing at the moment. I am just trying to build the null security community, which sometimes is more hectic than even paid work that I do.

ME — What do you advice the newcomers who want to hop on to the information security bandwagon?

AM — There are enough and more avenues to learn, enough documentation, learning resources. What is required is that they take up a topic and get some indepth practice in that. For most things that you need to practice all you need is a virtual machine, some software and good documentation. Get started with that and they can quickly build capability in this field.

I usually tell newcomers to learn the following to get started.

1. Linux and Windows

2. TCP/IP basics


4. HTML/ JavaScript

5. BASH, Python, Ruby, Java

Who am I

Well, aint it the most profound question!

I haven’t yet found an answer to this, however, i usually describe this body as-

I am an information security professional. I have some scary certifications that make people think highly of me till i open my mouth. Well….

This blog of medium is my renewed attempt (you seriously didn’t think that this is my first attempt at jabbing on the keyboard, did you?) to write about information security the way i want.

Look below for a more nuanced (and probably not-so-real) me:-

This body is much more than this

Please feel free to have a look around for the blog posts that i have written so far. A list of the articles that i have written elsewhere is also available here.