One thing that seemed to be universal amongst my colleagues is that they all hate being audited. Since I used to be an auditor (please don’t hold it against me), I was thinking of writing a blog post on understanding and surviving an infosec audit. First though I decided to take a quick poll – I turned to securitytwits and asked people what they thought of audits. Although I only got five responses, the results were very surprising (to me at least):

• 2 people thought of audits as positive even if they can be annoying. (One compared it to a doctor’s visit).
• 2 people thought auditors could be positive because they could help bring attention to issues which are being ignored by management.
• Only 1 person had a negative comments, saying auditors were a waste of money.

I had expected the results to skew entirely the other way, so maybe an auditor field guide isn’t as necessary as I thought. I will however throw out two random thoughts.

1. Auditors are interested in what is measurable, not necessarily in what is meaningful (to you).
2. While you may not like them, management usually has to listen to auditors. While you can complain all you want, ultimately you have to either pass the audit, so you might as well stop the complaining and try to focus on passing.

I recently started reading Forbes magazine. The most recent issue has an article entitled “dodging data breaches“. Right up my alley, right? The advice given, was, to put it mildly, awful. Here are some of the articles main points (please note that I’m not cherry picking misstatements – these the main takeaways from the article).

• Make sure your processor is PCI compliant.
• Limit access to sensitive data internally, and employ separation of duties. Get a review from a QSA of your PoS equipment.
• Check that the company hosting your website uses an IDS and has a SAS-70. If they use an SSL cert, that’s great because it “signals that a host has taken extensive precautions to secure data”
• Look into getting data breach insurance.

Now I could spend some time making fun of whoever wrote this article and some of the ridiculous statements, especially those contained in bullet point three, but that wouldn’t do anyone any good. There is a greater chance that my CIO reads Forbes (or will read some other source that will quote this article), than there is of my CIO reading a paper on proper session management techniques. Insult this article all you want, but realize that this is what’s being seen by your management, and this is the point of view they will have.

Update (7/19):

I realize I never quite finished this post. There are some valuable things to learn here, although they’re about business and psychology instead of infosec. I’ve seen far too many brilliant infosec people not get their advice heard because they weren’t speaking the right language. Realize what point of view the author (and readers) of this article are coming from. They don’t have the time or skill to do a security review, so they look for shortcuts like PCI compliance. The business is looking for indications of security that are easy to understand, easy to evaluate, and can be easily shown to others if their due diligence is ever called into question.

The following is a sample conversation that happens a lot between security personnel and other IT personnel.

Security: We noticed vulnerability X in service Y on machine Z.

IT: On machine Z? That’s no big deal – we don’t use service Y anyway, so it doesn’t really matter.

Any security person know that rather than reducing the risk, not using the service actually raises the risk presented by the vulnerability. If you don’t use it, you probably also won’t remember to patch it, review it, log it, or look at it if something goes wrong. The IT person though thinks that if they don’t use the service, no one can exploit the vulnerability because it’s not being actively used. The simple reason for this communications failure is that people who specialize in risk always define it differently than everyone else. This goes for other specialists too – medical professionals have started talking about risk management in the last few years, and people who deal with investments have been talking about it for decades. We all though conceive of it a little differently, think about it in different ways, and most importantly, we conceive of it differently than the general public, which is why we constantly have conversations like the one above.

I’ve long thought that one of the problems with the information security field is that so often we’re separated into our own IT security group within the IT department (or another department), instead of being integrated throughout an IT organization. There is a lot that could be written about this subject, but I just want to talk about one aspect here – patching.

Because software bugs are discovered, patches are necessary. Since IT security was (and still is) in its own echo chamber, we kept repeating the same mantra over and over again – patch, patch, patch. It’s one of the first pieces of advice given to people when trying to explain how to run secure systems, and time to patch is one of the leading security metrics.

The problem is it doesn’t work. People hate patching. Large organizations don’t patch. There are a variety of reasons why patches don’t get deployed – a sensitive application, lack of vendor support, lack of time, lack of money, concerns about stability, etc.. etc. Those that do patch well usually spend so much time and effort on testing and deploying patches that it takes a serious toll on other activities, whether they be security related or not. IT security though never stopped to consider the root of the problem – the consultants, conferences, industry news sources, and professionals just kept parroting the same advice over and over – patch, patch, patch. When breaches happened we could just sit back coolly and say “see? this is what happens when you don’t patch.”

If IT security had left the echo chamber we might have heard what we’re just starting to hear right now – patching is broken. Other methods are needed. Software needs to be more secure from the start. Other after the fact alternatives to patching are needed. More robust defenses need to be in place to ensure that a single buffer overflow can’t destroy your entire enterprise. As an industry we need to realize that patching just isn’t working and find other ways of ensuring robust systems.

Car manufacturers used to recommend specific intervals for various vehicle services in their owner’s manuals – 50,000 miles for this service, 55,000 for another, 60,000 for a third. What they found out was that this was too complicated – people did not bring their cars in every 5,000 miles for a unique service. Now owner’s manuals list all three services as being required at 50,000. It may not be as accurate or as efficient, but it works because it’s easier advice to follow. By simplifying the maintenance people needed to do, they got a higher rate of compliance. We, as an industry, need to do the same thing – simplify the ownership and stop relying on the owners to be perfect custodians of their investment. Or we can continue to rely on patching and smile a smug smile with every new data breach that’s recorded.

I’m frequently asked by people what to check for when doing a web app review. Usually the people asking are other IT people and they understand the basics of security – they’re just not sure what to check. This request comes in a lot of forms – sometimes it’s a developer wanting to know what I’m going to do to their application, sometimes it’s a program manager wanting to know so they can explain to the business, and sometimes it’s a friend who’s been asked by management to review a legacy or purchased web app and needs a starting place. There are two main sources I suggest.

1. The OWASP testing guide. This is without a doubt the best resource. It’s designed for the person who is actually doing the testing, and contains all the details, the explanations, and contains all the testing you can think of. The only downside is that the current version is 349 pages long. (V4 is due out very soon, and will likely be longer). This is far more detail than most people want, and far longer than what most people can handle.
2. I’ve been looking for a sort of “cliff notes” version of the testing guide for a while, and I think I’ve found one that’s workable (sort of). The OWASP Application Security Verification Standards are clearly not designed to be a comprehensive list of things to test for a web app, and doesn’t contain any of the “how” aspects of testing, but it provides a quick list of things to check. At only a few pages long it’s much easier to read, and the verification requirements themselves are even shorter. Because it also provides standard for different levels of assurance, you can decide just how important security is to this particular app and review the appropriate controls.

I recently picked up “Securing the Smart Grid“. In it they call out power companies for having a low level of infosec awareness when it comes to web apps, and have a few redacted examples to prove it. One of them is a screenshot of a login form that’s available over http, and also includes a message to the users that they may get a security warning but should just acknowledge the message and move on. I was aghast. I was also intrigued, and with a little help from google, I was able to locate this login form in about 2 minutes. (I simply googled the warning message at the bottom). The offending company is constellation energy, and the login form is here. I gotta say, if there was an award for ‘worst security practice of the year’, this might be a candidate.

update: After I made this post, I found Constellation’s twitter feed and sent them a note. As of Monday morning at 8:30, the page is now returning a “Service Unavailable” message. If you’re morbidly curious, the google cache of the page can be see (at least for a little while). For the record the form was not only accessible over http, but the form action was submitted over http as well. The warning message that was at the bottom of their page read as follows:

Note:   After submitting this form, you MAY see a warning message about redirecting to an unsecure document. Please acknowledge the message and proceed.

I also noticed that the notice at the bottom of the page says “Rev April 2002″, which may explain a thing or two about why it was designed the way it was designed. (I also noticed a few other poor security practices in that login form, but there’s really no need to beat a dead horse). Kudos to CEG for responding so quickly.

If anyone from CEG is reading this, you may be interested in my next post, which I hope to make in a day or two.

With everyone else doing their predictions for 2011, I figured I should get in the game and make some of my own. To save time in advance, I’m also making these my predictions for 2012.

1. The prefix ‘cyber’ will continue to be greatly overused by the non-technical, especially the media.
2. Something (malware, infiltration, data breach), will occur that will be declared the most complex/dangerous/expensive of all time.
3. Infosec professionals will continue to complain about how bad a cert the CISSP is.
4. Infosec professionals will continue to obtain CISSP certifications en-masse.
5. Some new wicked-cool feature, toy, or tool will be released that everyone in the world will want. Security people will try to warn the public of the risks this new device poses, and will have no impact on the new device’s adoption or sales.
6. ‘Privacy experts’ will continue to warn the public and gain media attention, and the public will continue to ignore them.
7. Users will continue to choose weak passwords, and we’ll pretend that this shocks us.
8. OWASP will continue to be awesome.
9. We will continue to be hampered by lack of information, and unbridled complexity, and will somehow manage to do our jobs anyway.
10. The earth will continue on it’s orbit around, water will be wet, summer will be hotter than winter, babies will be born, people will die, taxes will always be too high, and next year we’ll do it all again. Have a great 2011!

Many people use mailboxes or mail forwarding services to mask their physical locations. (If you do a whois on this domain for example, you will get the address of domainsbyproxy.com – a company that exists to hide the physical addresses of their clients but still fulfill ICANN requirements by forwarding any non-junk mail to me). I was thinking tonight about how I would go about attacking this system if I really wanted to know someone’s physical address. Eventually I came across a great solution – mail them a GPS tracking device!

Gawker was recently hacked and a huge number of password revealed. I’ll leave the repetitive and vapid comments about how weak everyone’s password were to others. Instead I’ll note something interesting. When looking at numeric passwords, those with an even number of digits were far more common than those with an odd number of digits. For example 123456 and 12345678 were both more common than 12345 and 1234567.  Other common numeric passwords were 111111, 666666, 1234, 123123, and 654321, all of which have an even number of digits. I commented on this once before in the context of voicemail passwords, but unfortunately I’m still no closer to a guess as to why this should be the case, although I suspect something innate to the ways humans remember things. Does the human brain find it easier to remember a string of numbers in pairs? Do people just like even numbers more? Are there any psychologists who want to do some research on this?

AppsecDC is all over and it was awesome. A whole lot of great presentations and I met a lot of great people. It was also my first time presenting at a conference. I didn’t think I’d be nervous, but I realized halfway through the talk that I was speaking fast and I couldn’t seem to slow down. For anyone who is interested, I’ve uploaded the slides from the talk is both ppt and pdf format. I’ve also set up a page on Domino security which has lots of resources. I will actually try to keep it up to date as there don’t seem to be many other good resources on Domino security.