Following the White Rabbit Blog : application security

Defining Security as a Business Requirement

RafalLos — Thu, 05 Feb 2009 04:53:00 GMT

This post is a follow-up to the previous one on QA: Defect vs. Vulnerability. All the highly-intelligent responses I received got me thinking further, and so here I present my additional thoughts.

This may not be revolutionary - but given the response I received regarding the terminology difference between defect and vulnerability I think the only logical conclusion we can reach is that if security is not a foundational business requirement, we're sunk.

To expand on this point a little more I think it's important to follow non-technical critical-thinking here. Anything that does not make it into the functional specification of an application [web or otherwise] is an afterthought. It has been conclusively [and repeatedly] proven that anything that is not "baked in" as a requirement is nearly impossible to fix later on, as an after-thought. So we're presented with a puzzler. Security must be a business-level requirement. So how then does one translate vulnerabilities into a business requirement, sanely? Simply stating "... the application shall be free of unintended design flaws and security vulnerabilities" is like asking an architect to build a structure that will withstand every known (and unknown) possible attack - it's simply illogical.

Strangely, program leads that manage these large-scale web applications at the heart of nearly every major breach want concise, identified things to not put into the code... but since that list is a moving target the security team gets penalized for the nature of security itself. This is the reason why black-listing input is a losing proposition... you're always going to be in an arms race with the bad guys... and you'll never win.

I've heard some recent conversations hit the wire around using the CWE Top 25 or some other list as a definitive list of coding errors to avoid in web applications but I'm not sure if that will actually solve the problem. The problem with this approach is and will be that these lists are exclusionary measures. These lists illustrate what we must exclude to be [more] secure. Turning it around and making statements like validate all input makes little more sense, especially given that input validation must be defined in the context of the situation, and there is never a one-size-fits-all answer. To illustrate the point further - input validation may mean excluding certain character sets/patterns and pre-defining acceptable input options ... but this does not account for things like free-form input or other use-case specific examples.

In the end, the crux of the problem lies in the nature of security vulnerabilities. Security vulnerabilities are a moving target and although they can be loosely defined and lumpted into Top 7/10/25 lists it is not logical to consider these lists complete or even functional for designing software. Will a web application be secure if it follows the CWE Top 25 and addresses those issues? What about the OWASP Top 10? I don't think anyone has that answer, or at least is willing to stake their reputation on it.

So back to defining security as a business-level requirement... can it be done? Can one clearly articulate requirements to secure data/transactions/processes/whatever *before* the technologists get involved; meaning, before the means to execution are defined? I will leave that up for debate.

Web Application Security - Vital in Academia

RafalLos — Tue, 20 Jan 2009 03:05:00 GMT

"Police: School data hacked, grades altered"

http://www.republicanherald.com/articles/2009/01/15/news/local_news/pr_republican.20090115.a.pg1.pr15hacker_s1.2230498_top4.txt

Every once in a while, we get a great example of why web application security is vital no matter where in the world you operate. Even though academia often feels like they are the exception due to lack of funding, chaotic environments and a cornucopia of other reasons we occasionally read a news nugget that proves they are just as needy as the rest of the business world of good web application security.

An article in the Pottsville, PA Republican Herald, posted last Thursday January 15th, 2009 identified an incident that caused a bit of a ruckus.

"Pottsville police anticipate filing charges against one or more computer hackers who unlawfully made changes to an online grading system used by Pottsville Area School District.

“You had some people who hacked into a school-functioned, online site and found ways to change data that was put in there,” Pottsville police Capt. Ronald J. Moser said Wednesday

“In this case, someone figured out a teacher’s login and password. It is still a federal offense,” said Monica Langenberg, Shawnee, Okla., director of business development for Classroll.com."

There are several things we can gleam just from that critical quote... let's address:

First, this incident highlights the dangers of having publicly accessible grading systems and school-tied information available on the public Internet. Perhaps the school system should evaluate the sanity of having such critical information for its students protected by a simple username/password system available to the whole of the Internet?
Unless I misunderstand the content of this article... no one "hacked into" anything... the students simply guessed the login credentials of a teacher, who, coincidentally should be held accountable as well for having easily guessable credentials to such a system
A "federal offense"? That's fascinating...
The student demonstrated lack of malicious intent in my view, simply by making the types of changes that would get them caught... it very well could have been done silently over time to really cause some damage

What does this teach you, if you've in academia and evaluating or building an online system like this? Secure it. Base-level login/password authentication from 1999 isn't going to work... Also because of COPPA (Child Online Privacy Protection Act) there is some much greater accountability for academic environments when it comes to protecting children and their information.

Harsh Reality - Life in InfoSec

RafalLos — Mon, 08 Dec 2008 20:13:00 GMT

It's Monday again, and it's absolutely brain-numbingly cold here in Chicago... but I wanted to get these thoughts down before they fell out of my brain to make room for new stuff.

Last week I had the pleasure of meeting with a group of guys that are running the Information Security practice within one of the largest and most respected retailers to the "hip" crowd... these folks live sales volume and press... good or bad. I think they've got some extremely unique challenges so I wanted to present the angle I proposed in case it's useful to anyone else.

First off, they have a very small "security" team, mainly consistent of compliance activities and common "operational security" tasks such as identity provisioning, anti-virus, firewall, you get the picture. They also have a relatively well-established QA team which is critical to the success of their online retail component - so the established value of that team is there. This is unlike the value of the security team - which unfortunately doesn't have a good foot-hold... not for lack of trying from what I heard. Their problem? No one cares about security. (Sound familiar yet?)

To overcome some of these challenges we focused on what was important to the business from an IT perspective - Software Quality. More specifically the quality of the online application(s) was important to this customer. Having their eCommerce site(s) up, and available for business is top-priority. Given that information we can quickly re-tool our approach and make *security* a component of the overall quality cycle. I know, some of you security purists are probably mad at me right now, but this is the harsh reality of life in a downturn. Why not though, use the business-critical areas to get the job done? The Security guys know they need tighter security but maybe the business doesn't care so much - except to check the box of compliance (PCI-DSS) - so I think taking a modified approach is the only way to fly in cases like this.

Making security a sub-component of overall software quality works like this. Security, amongst other things, aims to keep a site/application "up and running" and resistant to hacking. Now, hacking often-times causes Denial-of-Service conditions so there we have link #1 to quality and uptime. The second link comes in a little more vague. Hacking an application means loss of data, potentially - and that can lead to downtime and disrupt the consumer's ability to purchase or buy - basically data corruption. I know these aren't ideal links, and you'll like the PCI "compliance" link even less I'm sure - but there you have it.

Those 3 links into application quality may be the difference between *zero* security budget and getting *some* security budget. Now, the question of TTH (from Jeremiah Grossman, Time-To-Hack) may come into play again... we have to ask ourselves if what we're doing makes any difference in the time that it takes to take the app down, and steal the data. Maybe yes, maybe no right? The main point here for these guys is to demonstrate due-dilligence for PCI comliance. While this is a bit of a sad commentary on the way of the world and how much security *really* matters... at least they're doing something.

Keep pushing guys, you're on the right track!

ViViT - Madison, Wisconsin

RafalLos — Tue, 02 Dec 2008 22:02:00 GMT

Those of you in or around Madison, WI ... come see me talk about Application Security Governance on Thursday, December 4th. If you need more information, contact me directly and I will send you the event invitation.

This should be a great event and a chance for a lot of informal conversation and panel-type discussion. See you there!

Obstacles to Building a Successful Security Program [part 1]

RafalLos — Thu, 04 Sep 2008 03:04:00 GMT

Since February, I've been traveling and meeting with IT Security leaders, CISOs, Program Managers and other folks in charge of application security for their business and a few themes have recurred. I'm fascinated by the differing scenarios and situations that security leaders are placed in but it's even more interesting to know that many of you are in the same boat.

It's clearly *not* that security leaders don't want to build well-integrated, holistic application security programs, that much is certain. The problem is no one that these security leaders report to *cares*. It's just baffling how many of you are faced with a compliance exercise, client requirement, or some internal need for "proof that application security is done" but have so little power to actually do anything more than the bare minimum.

I guess it's telling of the times we live in, and perhaps also indicative of the state of the world economy when we are asked to forgo the "strategic" and chase the "tactical" solutions. None of you will argue that the tactical solutions [one-time code reviews, single point-solution tools, etc] is a good idea but this is what you're required to execute on, and then move on to the next fire-drill item. It's enough to drive a person mad.

Well... I know of at least a few of you [and hats off to you, you know who you are] that are finding ways of making the long-term, strategic and holistic programs work in your business. It clearly takes some creativity and guts - but you're doing it. I'm going to, over the course of the coming days, document some of your endeavors, the struggles, the failures and successes - names will be left out to protect the innocent, of course. Now would be a good time to pay attention folks... there are some real lessons to be learned here, and maybe you can use something and take it back to your business or career and build off these stories. Until next time...

Building a Web Application Security Program Without a Budget

RafalLos — Tue, 29 Jul 2008 20:12:00 GMT

As promised, I'm writing up the first segment of implementing a web application security program without having to spend (or add spend to) your own budget. The current economic conditions are stiffling technology investments and security programs aren't much better off than they were this time last year. In fact... security's budgets have shrunk. I know, no one reading this is shocked.

What I am going to give you some support no here in this first piece is gathering the information you need not to have to spend anything. This is quite simple, but rarely done I assure you.

First thing you should do is infiltrate the opposition. In case you haven't noticed, critical business functions rarely get their budgets cut so in order to get the same type of treatment you have to learn what they're doing differently than you. Follow these simple steps, and you'll be one step closer to program success.

Identify the heads of each of the following departments within your organization:

Fraud
Risk
Legal
Compliance

Ask them for their list of initiatives for next year and beyond
Ask them to identify which of those initiatives have a "Web application" component
Sit with them in their office at least once to understand their priorities, and reasoning behind those priorities
Provide feedback for each web application-related component to identify "security needs"
Confer with the owner/sponsor (person whom you sat with) to ensure those needs are "baked into" their budget estimates
Add each of those projects identified in #6 to *your budget* with a dollar-amount of zero (insert reference to #6 above for clarity)

Alright. There you have it. These are the steps that I've personally successfully used in the past, and I know that this works a good majority of the time across a wide range of companies and industries.

Now that you've got this gameplan ahead of you... you may need some coaching on how to position your requirements to the various department heads for step #6 in the process. I'll detail some of those tricks next.

Input Validation Strategy - Black vs. White -listing

RafalLos — Thu, 26 Jun 2008 17:00:00 GMT

[This post is a little lengthy, but necessarily so. Get a beverage, sit back, and learn something]

I've recently spent some time in front of a group of development-oriented professionals and the talk I gave broke down at a certain point, and I felt like I needed to write this one up. What happened was not entirely unexpected but I was a little surprised at the tenacity of the group in their arguments. At one point I felt like I was going to be chased into the windmill by the villagers and burned... The good news is these developers were willing to listen which is all I ask for.

The debate over whether to default-deny or default-allow is one that extends well beyond the web application security world. In fact, this is a principle that's applied to the real-world all over the place. Night clubs, airport [in]security (*chuckle*), and many other examples of this type of methodology abound. Perhaps the quintessential example of default-deny (white-listing) is the operation of 99% of the world's firewalls. When we all started building networks we would block the bad stuff and allow everything. Over time (and quite quickly) we security folks realized we were getting beaten, badly, as the bad guys could come up with attacks faster than we could close off ports, so we changed our approach. The new approach was to default-deny everything and only allow what we knew was OK or supposedly semi-trusted. Over time this became the standard and now I feel it's time for the Web Application Development comunity to start thinking of this or face the harsh lessons (or continue to face those harsh lessons) like we firewall jockeys did back in the day. Let's first address the concepts, just to make sure everyone has the same baseline. The two main concepts at odds are white vs. black-listing for input validation and sanitization. A quick explanation of the two works like this:

Black-listing: Allow anything, and create a list (blacklist) of disallowed characters, or character combinations (typically done through a Regular Expression RegExpr)
White-listing: Disallow everything except for specifically identified character sets and combinations (typically done through a Regular Expression RegExpr)

Now that you have the basics down let’s cover the question of which is appropriate. Of course, everyone has their personal take on this topic but I honestly do feel like there is a right answer here. I’ll present the facts and will reserve my personal comment and recommendation for the end. Since most web applications are built with maximum user operability and compatibility in mind, blacklisting generally sounds like the immediate better idea. Immediately when validation is brought up to developers the question of complexity rears its ugly head. Why not just allow everything and have some “security device” (software, hardware, whatever) do the security checking? The simple answer to that question is this – if you rely on a 3^rd party “bandaid” device you’re in trouble from the start. Security must be done at the heart, in the belly of the beast, inside the application – where else does full knowledge of application content and context live? Having addressed complexity, and taking it as a given (some complexity addition is inherently necessary) we have to address the requirements of the application to figure out which method of validation is feasible. At the end of the day there is no one-size-fits-all solution to this problem. Each individual application must be analyzed and addressed page by page, form by form, field by field. The general rules still govern the task of validation though – simplicity is preferred. Always remember the KISS (Keep It Simple Stupid) principle when coding… or building anything for that matter. There are issues here which very realistically can make either option viable such as the need to input free-form text fields where a tolerance needs to be added (requires the characters < and > which are known to be used in XSS or Cross-Site Scripting) and when a name field will be accommodating Seamus O’Malley (the ‘ is a great SQL injection attack staple) comes up.

But think of it this way – pretend you own a night club (work with me here). You, the owner, hire a bouncer and tell him to monitor carefully who gets into your club. You start by saying no one in shorts and a T-shirt only to later find people on your dance floor wearing ball caps. You then add ball caps to the disallowed list only to notice sandal-clad patrons. You then add sandals to find cut-off jeans… and on and on. Finally you get annoyed and create a new policy, only people wearing formal dress-clothes are allowed in, everyone else stays out… this is a much healthier approach than trying to continually keep up with what the next unwanted trend is. This is identical in the development of web applications. You don’t want to spend your days and weeks into eternity trying to continually update your “blacklist file” with all the things that are disallowed, and building regular expressions to disallow them. You’re never going to be done, and there will always be some permutation of an attack that will slip past you.

By now the benefits of white-listing should be apparent – but what if you run into cases where a simple white-list isn’t appropriate? What if you do have to allow most-characters in the English character set? Are there cases where the only real and viable approach is to build black-lists? The answer to this last question is an emphatic yes. Just doing one or the other often either entirely fails, or becomes very difficult to work with. For example, if you have to include the greater-than (>) and less-than (<) characters – you should write regular expressions to make sure that those characters aren’t part of a script tag … right? My point is this – you’re never going to win trying to keep up with the hackers by building a black-list. I can personally guarantee you this. If you’re extremely lucky – and very good at security/programming – you may be able to hit a 30% effectiveness with black-listing. That’s still overwhelmingly poor… I would hope you understand that. But… in conjunction with a white-list that is well defined this could make your application not only safe today – but also future-proof your code. If Cross-Site Scripting (XSS) is what you’re worried about… then you can feel pretty safe is your server-side validator throws out any non numeric characters [0-9]. You can build code that is resilient to future attacks (not 100% future-proof, mind you).

So there you have it…the low-down on validation based on white/black-listing. Which is appropriate for your application? Only you and your security team will be able to determine that based on specification, functional requirements, and security need.

Wrong Message, Wrong Audience

RafalLos — Tue, 17 Jun 2008 03:26:00 GMT

You're delivering the wrong message, to the wrong audience.

Don't believe me? Let's look at the attendance of workshops and conferences - now look at the message that's being delivered. I'm speaking of course specifically on web application security here. A recent article on Jeremiah Grossman's blog made me think, what do we (as security professionals, and industry "experts", do?) I feel like it's our responsibility to educate and bring the correct message to the people who will really benefit. Interestingly enough, I feel like we're failing to do this to any beneficial degree.

It's one thing to want to deliver software security as a message but an entirely different thing to deliver it to the right people who will actually benefit from the message. I honestly feel like I can't stress this enough.

I think it's wonderful that security is being preached at conferences all over the place, from quality to engineering of software to process management - but the real shortcoming is in who is hearing specifically which message. As a speaker I can tell you that if I deliver the same message to every audience it will be lost more often than it is understood. Tailoring the message is so important. "The message" can be what ever you're delivering on - for me it's mostly how to build better web-based applications resilient to subversion (otherwise known as "hacking") but again - this can be whatever you specifically are trying to convey.

In order to understand how better to deliver a talk with some punch the key is to understand the audience... I've taken my notes from the past several months of conference speaking and will deconstruct the audience for your benefit here...

Management - Of course managers to go conferences, workshops, and talks because every once in a while they feel the need to stay relevant. I can say this without reserve because I was there, and I know for a fact that most managers are so busy trying to make sure their teams are delivering that they often have very little time to do much else - and by the time they look up from their desks technology has passed them by and they are relics. The answer to this is to hit a conference every once in a while and hear what the topics of the day are - a wise choice indeed. The manager as a target audience is very complex but can be simply deconstructed as follows:

Goals: Understand the high-level message being delivered, the current topic and how it applies to their daily life as a steward of the business
Challenges: Unfortunately, being that few managers are really current on technical speak it's very easy to lose a mangement audience in the details, while they want to hear your message don't over-complicate it
Win-Win: Present the topic in a way that can both delivers your point without losing meaning while at the same time making it relevant to the manager's everyday work-life... a tricky thing, I know!

Developers - Developers are a rare gem at conferences where security professionals are speaking, sadly. Developers are keen on making stuff run faster, better, and making their lives less complicated. Notice that I didn't necessarily mention security in the stuff developers are keen on - it's our job as security folks to get them excited about writing secure code and getting them to come to conferences and workshops is a great start but the issue then becomes the way in which we deliver the message. I'll deconstruct developers here:

Goals: Learn the hot new "hacks" and cool code ninja skills which make them more marketable and give them greater ability to innovate and build something truly incredible with their code skills. Developers want to be able to write cool code, faster, and with less effort, period.
Challenges: As I've already pointed out, security doesn't often factor into the mind of a developer. We've been trying for years to change that and to some degree it's working but the percentage of security-conscious developers is still very, very low.
Win-Win: Developers aren't necessarily purposefully ignorant of security, just call it...agnostic. If we can find a way to make writing secure code less painful, and more... developer-centric they'll adopt our principles and everyone wins.

Security Professionals - Preaching to the choir, althoughit's often the choir which hasn't heard the message. I can't tell you how many times I've been in front of a security-oriented group presenting and they're looking at me like I'm a talking Polar Bear... seriously. Security professionals have a hard time keeping up with the technologies they support - it goes with the job - and so hearing something that's a niche piece is often intriguing but we have to find a way to make the message stick! Let's deconstruct a security audience...

Goals: Hear the message, learn the "cool hack" they can take back to their team/manager to feel like they're abreast of security. In security it's all about staying relevant and up-to-date and niche presentations attract security people like flies to honey.
Challenges: Quite simply put - the challenge with preaching to your own audience is that they see things in black and white. Security peers tend to see web application security in a binary fashion; secure or not. This creates a problem some of the time as if we deliver a strong message, say on a new AJAX vulnerabiltiy, the security staff can miss the forest (in this case the 'big picture' of security) for the trees (the specific new "hack") and actually do some reputational damage to themselves within the realm of corporate IT
Win-Win: IF we can provide the right amount of guidance with relevant knowledge we can spur security professionals to make better policies and serve their business better. The goal for us as speakers is to blend technology with intelligence to help mold the perfect security professional - one that is business savvy and security smart

"Engineers" - This is the catch-all category, as far as I'm concerned. These are the other people who don't necessarily fit into the stack above. You've got a mixed bag with this, and it's a challange to make it work, but I'll deconstruct this audience type thus:

Goals: Learn something, take it back and apply it to work - maybe, if it's relevant and applicable. (The secret is since we're talking security it's always applicable)
Challenges: Making security a relevant topic. How do you make web application security relevant to a generic group of IT people? Blend the right amount of technology (so as not to go over anyone's head) with the aspects of IT that make it important to just about everyone - make security "real" with examples from all different sources
Win-Win: The best-case scenario here is to make an impression on someone so that the next time someone says security - they flash back to your talk and recall the message you gave, and as a bonus attempt to apply that (or at least know where to get more information, and point someone there).

There you have it. I hope this has been helpful - so that the next time you're standing there in front of your audience you've got the right mindset and the right goals, challenges, and winning strategy.

Good luck!