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

Technology
People
Process

Technology

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.

People

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.

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.

Process

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 (https://en.wikipedia.org/wiki/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 —

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: –

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).
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?)
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 https://www.acunetix.com/wp-content/uploads/2014/03/reflected-xss.png)

3 — Understanding the impact of XSS (either by pestering the penetration tester to prove it or going through online examples like this URL — https://security.stackexchange.com/questions/1368/can-anybody-explain-xss OR http://www.12robots.com/index.cfm/2010/9/14/whats-possible-with-xss–security-series-81)

4 — Ability to explain, with example of, XSS code (e.g., something like this URL — https://security.stackexchange.com/questions/1368/can-anybody-explain-xss)

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:-

The process of going from one place to another
The process of translating requirements into working software
The process of capturing requirements from client;
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:-

Does it account for the existing capabilities of the team (in other words, can the existing team do it, with their current skill set)?
Does it provide a way to not only repeat the success, but also to record the failures?
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:-

Technology and process is appropriate but people with required skills are not put to implement the process;
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.);
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.

Client Data Security — Why and How

I have finally decided to break the jinx of not keeping my blog updated. I shall update it once a week. Here’s the post for this week.

In today’s fast changing business world, regulations related to security are pervasive, so much so that with every new project (whether in the same or a different geographical region as that of the client), comes a whole set of laws to carry out (to the letter) as far as client data is concerned. If there is anything that the law misses, it is covered in the contract.

The next question is — why do client put these clauses (related to their data privacy) in their contracts?
They put it there because if the information leaks/gets modified, the client is liable to suffer monetary & intangible losses (lawsuits, fines from government, damaged image, lost clients, etc.).

Hence, in order to make sure that we understand and commit to the security and privacy of client information, they put the relevant clauses in the contract.

Bottom line — client data is sacred, and any security issue related to it can come back to haunt us (legally and otherwise). Hence, it makes business sense to protect our client data.

This poses some challenges.

The challenge is — No one, in their right minds, would want to put client data at risk. However, by virtue of our work & our focus towards it, security sometimes takes a back seat. This is reflected in our activities (we can also call them habits, as they keep happening from time to time). Some of them are (the list below is indicative):-

1. Noting some crucial information on a piecec of paper and keeping it at a public place;
2. Sharing password so that any client information that you have is now easily accessible to others;
3. Not keeping your anti-virus software updated;
4. Clicking on a link in mail without checking it first;
5. Discussing/sharing sensitive client information with people who do not need it to do their work;

Human beings are creatures of habit. Habits are very important in security. If i have a habit of sharing my password, there is a high chance that people near me (with good or bad intentions) can get access to it; further, if i have a habit of not locking my machine while going away, it is possible for someone to look at a crucial information (of client or personal) & make use of it.

Below are some habits that are found to be helpful in increasing the security quotient of a project, and should be used by all to ensure that we do not compromise the security of client information:-

1. Secure your passwords
While it is not always practically possible to remember a password that resembles Garnier Fructis (Long and Strong), one should understand that once you put a sensitive information like password somewhere other than your brain, you should protect it, lest it get into someone else’s hands.

2. Do not share your passwords
Once a password is shared, it is no more yours. If you have to share it (due to project requirements), make sure that you do not re-use that password for any other purposes and that you change it as soon as possible.

3. Keep your anti-virus software updated
While anti-virus software usually are put on auto-update by default, it pays to be vigilant and update it manually if the update gets failed (e.g., due to bad network conditions).

4. Be careful while clicking a link
Most of the bad code (virus/trojan/worm, etc.) require your effort (unknowingly, of course) to get onto your machine. We do so by clicking on some link without checking it first, thereby getting a bad code on our machine.
Always check a link (by putting your mouse over it, not clicking) before clicking it. If the link is pointing to a direction (e.g., an IP address or some mis-spelt address), do not click it.

5. Do not share client information with anyone who does not need it
Now this is tricky! How to find out if the person who is asking it needs it? A rule of thumb is — if the person does not belong to your project and is not authorized by your respective manager / superior, he/she should not have that information.

6. Lock your machine while leaving it unattended
Leaving your machine un-attended is a dangerous habit as almost all the access rights/privileges are attached to our machine identities. As one moves up the corporate ladder (and sometimes depending on the project requirements), one gets access to information that is confidential in nature. This habit of leaving the system/desktop/laptop unattended & unlocked may prove disastrous (Think someone-stealing-a-file-that-your-VP-sent-for-your-eyes-only)!

Bait for Your Identity

I overheard this interesting talk last sunday while harassing some poor developer to close an NC, have a dekko. But before that, a very short intro of the characters.

Character #1 — Baba Gyandev, aka if-google-had-a-body-this-would-be-it, BG in short

Character #2 — Baby Busy, aka this-will-never-happen-to-me, BB in short, BG’s follower#1

Character #3 — Paranoid Pandu, aka even-my-breadth-should-be-encrypted-to-save-it-from-sniffing, PP in short, another follower of BG

Context — BG & his disciples are in a very good mood. BG is happy because of planetary alignments, BB got a good appraisal recently, and PP just bought the latest encryption software for his laptop. More than that, they are happy because of their body has been treated to the best seafood meal that they had in recent times.

BB — This place is good, we should come here more often.

BG (after a big gurgling sound escaping the deepest corners of his intestine, making everyone else in the restaurant look for cover) — Yeah, fish is good.

BB — I don’t know why some people have devoted themselves to anti-fishing causes on Internet, it is not if we are trying to finish all the fishes!

PP — That was not this fish, BB, it is called Phishing, and it is very dangerous.

BB (with some alarm on her face) — Oh!

BG — PP, please do not terrorize her. BB, while it is true that phishing is a concern, it can be managed by some very easy-to-do things.

BB — Baba, please tell me more about this. What is this about?

PP — It is about stealing your identity.

BB — My identity? What identity?

BG — Bhaktjano, it’s not the identity that all of us are always looking for, inwardly (who am i? What am i on this earth for, stuff like that). I can talk about it more over seafood in Taj Banjara. The identity, that we are talking about now, is that of us on the information superhighway called Internet.

BB — Identity on Internet? What is my identity on the Internet?

PP (with some irritation) — Don’t you have a facebook account? Or yahoo/aol/hotmail/gmail ID? Or any other ID on any other website (irctc/icici/sbi/any-other-bank)?

BB — So what? Those are just login IDs, not my identity, Mr. know-it-all!

BG — Please don’t fight, kids. BB, in today’s online world, everything is connected to everything else on the Internet. You can share content of one website on another, e.g., share an online article or a review of latest movie that was put on some other news site, on your facebook account; you do a lot of financial transaction online. All of this requires that those sites know you. They give you login IDs so that they can recognize you, the next time you logon. So, all these IDs that we have online constitute our online identity. It is what we are and how people will recognize us when online.

BB — Yeah, i remember opening a recurring deposit account online in ICICI. They neither made me write a letter nor call me for an approval. I started it online and it automatically deducts money from my account every month.

PP — That was because they knew it were you, because they knew the login ID belonged to you.

BG — Correct. But now, the issue is — Crime always follows money. Bad people have realized that many (if not all) of the transactions are happening online now, it makes more sense if we can somehow get those IDs and passwords.

BB — Hmmm….. Baba, how do these people do it? Where does Phishing comes into picture?

BG — They will create copies of the well-known websites, with similar spellings, and put them online. Then they wait for you to land there.

PP — They do not always wait for your to come, they try to lure you to it. Remember that LinkedIn invitation that you said you had got from me? And the facebook invitation from your husband?

BB — Yeah, i do. I also remember that you had a look and then asked me to delete them and not to click on any link in that mail.

PP — Because it was a SPAM, meant for anyone who would believe and click on them, thereby landing on the fake site. The person will provide his actual user ID and password, and then, la-la land!

BB — How to stop it?

PP — These people are a reason why i am very skeptical while online. I don’t trust Internet!

BG — PP, in that case, stop buying house because land mafia may take it over, stop buying gold or silver ornaments because they can be stolen, stop carrying money in pocket because they can be , well, picked up. And while you are at it, stop living (PP looks at BG in shock) because there are criminals out there who murder for living.

BB starts laughing.

BG (with increased calmness) — Just because there are some issues with a technology or a facility, you don’t stop using it. Atleast not when you get so much benefits from it. More so, when you can save yourself using some common sensical tips.

BB — Please give me some tips so that i can save my identity online.

BG — the first step – don’t click on any link blindly. Check it before clicking on it. Is it pointing to what it says it would?

PP — A link to facebook should not go to some random site like gimme-your-password.com

BG — True. In the lower left hand corner of most browsers users can preview and verify where the link is going to take them. Always check them before clicking.

PP — Also, look at the language of the mail.

BG — In other words, do not click on links within emails that ask for your personal information.

PP — True. Actually, no organization in its right mind would ask for it in mail. If it does, there is something ‘phishy’ there.

BG — Never enter your personal information in pop-up windows.

BB — What is wrong with pop-ups if it comes up after the original site has loaded? It means it has come from the site, right?

PP — Not necessarily. Sometimes a phisher will direct you to a real company’s, organization’s, or agency’s Web site, but then an unauthorized pop-up screen created by the scammer will appear, with blanks in which to provide your personal information. If you fill it in, your information will go to the phisher. Legitimate companies, agencies and organizations don’t ask for personal information via pop-up screens. Install pop-up blocking software to help prevent this type of phishing attack.

BB — Means, i should never give confidential information in pop-ups.

BG — Correct. Also, phishing doesn’t always need Internet.

BB — ?????

BG — You may get a call from someone pretending to be from a company or government agency, making the same kinds of false claims and asking for your personal information.

PP — If someone contacts you and says you’ve been a victim of fraud, verify the person’s identity before you provide any personal information.

BG — In other words, don’t give (or offer to give) your account ID and password to some guy over phone just because he claims to be from IT-Support. I know you did that yesterday.

BB (blushing) — that was because i needed some document very badly but was not able to logon to my machine. I had raised a ticket too.

PP — How do you know that this guy had called because of that ticket? I was there, too and you did not verify his identity.

BB (getting a little angry) — There is nothing interesting in my account, even if the user gets the password.

PP — yeah, true, but you re-use passwords, right? Which means one password of yours can open many accounts of yours !

BG — Actually, it is not just a matter of having something interesting in your account. Once your account is compromised, it will be used by bad people to lure your friends and contacts.

PP — For example, if i get your twitter / facebook / gmail ID, i can just ask your friends from little money (i can guess who are your friends by looking at your past activities), and if they are like you, they will transfer money first and then call. And that is just for starters.

BB is silent.

After some time, BB breaks the silence.

BB — So what should i do to stop it from happening?

BG — Be suspicious if someone contacts you unexpectedly and asks for your personal information. It could be in any format (online or offline), but ultimately, you have the responsibility over your information, Keep it secure!

PP — You can also keep changing your passwords regularly and use security features available with major sites (like two factor authentication of gmail, privacy features of facebook, etc.).

BG — Keep your browser and operating system updated and secure because many phishing attempts are hidden in viruses and other bad code.

BB — Baba, what if i accidentally gave some information? What should i do then?

BG — Contact related officials immediately and inform them.

PP — for example, if you accidentally gave your banking related information, then contact the bank immediately. In case of an online account, change the passwords immediately and notify the website.

BB — Thank you, BG and PP.

OpenSAMM — Part 01

This is part of a series of presentations that i am going to create for explaining an open secure SDLC maturity model, called SAMM aka OpenSAMM. Click here to view the presentation.

Disclaimer — This is NOT an original work. I have taken help from the official presentation and some other articles/presentations available on internet. I regret that because i forgot to keep track of the sources, i cannot credit them properly in the presentation. However, if i get any information about the source, i will update this presentation with the credits. Would request people to get back to me if they have information on the sources.

Although it is generally believed that security should be in-built and not a patch after development, very few companies give it a try for one or more of the reasons:-

There is little explicit demand (after all, my customers are not saying they want security, why should i bother? If i put some investment and cannot get it back, it’ll be bad for business, won’t it?);
As a corollary to the above point, clients probably worry that if they demand security, maybe they have to pay for it (in terms of additional efforts and hence cost);

However, with SEC demanding that companies disclose “potential” security breaches (and this usually means that apart from companies to take notice of this fact, us compliance professionals can take little sadistic respite in the fact that we would be in little more demand 😉 ), i think companies better start demanding security in their applications (at-least those that come under purview of SEC).

OpenSAMM (or SAMM) is a maturity model that helps gauge the maturity of secure SDLC implementation in an organization. It also provides a benchmark against which similar efforts from different organizations can be judged. In retrospect, isn’t this how ISO propagated (capitalism, anyone?). Business wise, i think it makes perfect sense to demand security from a service provider, and then benchmark it against those of other vendors, makes ROI sense.

I gave this presentation at an OWASP Chapter Meet. Hope to finish the entire series in a couple of months. Watch this space for more!

Sach Ka Samna — Some InfoSec. Myths, Busted

OK, I am not Rajeev Khandelwal, but like our world, information security has its own share of myths, that, over a period of time, have quite a collection of believers behind them, masking the truth. This article is an attempt to rationalize their bust.

Long passwords means secure system

Long passwords means one thing — I will write it somewhere!

No seriously. How else would I remember it ?

Does that mean we should shorten our passwords? Not really. The God is (as has always been) in detail.

What it means is that we have to be careful while choosing a password. Keep it easy to remember, yet tough for others to guess (yeah, all the best!). It also means that everytime we chose to write it somewhere, we are on our way to make our system insecure.

Oh, I almost forgot the mother of all password mistakes — sharing it with others!

Security is a trade-off. Be careful what you trade it for!

Keeping anti-virus updated will save me from viruses

Anti-virus industry is like cops. We all know the probabilities and outcome of a cop vs. thief. Cop has to win everytime, thief only once. What it means is, if you have a paid version AND the anti-virus that you use currently, is the market leader (tough to determine), you can sleep on weekends (in night, sometime).

Does that mean we should shut our systems down and dust our papers and pens off?

Update your anti-virus daily (and keep a licensed copy of it, please. Kaspersky has gone cheap. And no, I have not yet received any commission from them!), and while you are at it, keep a backup of your important data. On a separate media (not on a separate partition on the machine).

Also, think about firewall and getting it installed on your machine.

SSL is secure

Nothing is 100% secure. That small padlock icon means that the data between the client (your browser) and the server (where the website is stored) is encrypted. But it doesn’t mean that people cannot sniff the data (if the server is compromised, or if there sniffed the initial cryptographic key — classic Man In the Middle).

If I don’t access Internet from my machine, my data is secure

True. But then you have to stop using USB sticks, stop using CDs/DVDs. In other words, stop using your computer.

Bottom line, there are more ways to get into your machine than there are hair on my head (I am not bald!). What it takes to secure your machine is a collection of good security practices (including some boring work like patching your machines, changing your password regularly, not sharing your password, etc.)

Linux is more secure than Windows

While I personally like Linux (because of its power), it is also true that mis-configured (or one that is not configured at all) linux is no better than windows.

So, should we dump all our Windows systems and migrate to Linux? The answer to most of us is NO. One, we will have a hard time finding proper versions of everything that we require for our business. Two, the work associated with migration (including testing, and training) doesn’t make it a viable solution.

A possible solution could be to use Linux for some servers (like file and mail servers) while keeping Windows for clients.

Information Security Standards & regulations are just pain-in-u-know-where

I couldn’t agree more! However, regulations are there because they are response to some real pain that business had been facing for quite some time. Regulations like HIPAA, HITECH, SOX evolved out of a business need to secure customer data. Traditionally, they shouldn’t be present. Corporations/enterprises should have included security as part of their SDLC. More on that later, however.

We have to be worry about hackers

Reports have shown that internal threats are more dangerous than outside ones. After all, we know the loopholes, right? Problem is, not everyone is un-professional. People don’t do these kind of things very often (even in a cut-throat world like ours). However, the cost of one incident is so great (IP loss, loss of image, etc.) that organizations have to consider this threat as real. Where there is money, there will be criminals (real or virtual).

Further, increasing reliance on contractors, consultants, and outsource vendors increase the exposure.