5 Ways to Screw Up Application Security

So much has been written about building secure code. I thought it might be helpful to document ways companies can purposefully build insecure software. Ya know, just to be sure they can, if they want to...

First: ignore your industry. Building healthcare apps? Working in financial arenas? Your first and most successful approach to building insecure software is to ignore your industry and any related regulation or compliance requirements. Remember how your dad would lecture you that ignorance is no excuse? He's right, but if you really want to mess up, ignore regulation. This is the gift that keeps on giving: not only does ignorance make your apps less secure, it also opens your firm to numerous liabilities (for instance, healthcare companies who blatantly violate HIPPA technical requirements are now being fined). But wait--there's more: it also opens your company to class action lawsuits. Why settle for government penalties, when you can expose your company to civil fines, too?

Second: don't plan security features. Expect them to take care of themselves. This is step two in the ignorance approach--you can't just ignore regulations, you also have to overlook listing any security features your users might need. Planning ahead means security can be built into the app. By ignoring features, you set yourself up for bolting them on later. We all know building security in later is horrifically expensive. The silver lining to this approach is that the high cost of "later" generally renders "later" impossible. If you wait on security, senior management will usually prioritize shipping over fixing, and you'll be off the hook.

Third: by all means don't check for security in your source code. Fixing a flaw is infinitely cheaper if it's discovered the day it's written. Static code analysis tools like Checkmarx SCA are low-cost, high return tools developers can use to detect flaws when they're introduced. Checkmarx can even be tied into the build process and used as check-in and nightly build tests. Acceptance tests and security functional tests should never be run.

Fourth: don't ask "what if" questions. This important step is tied tightly to the ignorance step (step 1). Building an app and you want some instrumentation? Looking for usage data inside of your app? There are third parties to help you do that. When you integrate these third parties' technologies, be sure to not ask questions like "what could possibly go wrong?" or "what information are we sending?" These questions usually result in discovering security issues (like the integration of botnet-like command and control channels) or compliance violations.

Fifth and most important: do not, at all costs, allow developers time to educate themselves on security. An educated developer is by far the greatest enemy of insecure code, because the developer implements the code. In addition to denying any requests for SANS training, be sure to block access to OWASP.org, BSIMM.org, SAFECODE.com and anything with "secure development" in its content. The unfortunate truth for teams seeking to build insecure code is that it's just as easy to build secure code as it is to build insecure code. Not only that, but it takes a developer almost the same amount of time to write secure code as it takes to write insecure code. It doesn't take much to keep your developer in the dark. Related to this is the idea of planning and executing penetration and security testing. By putting these tests on your product plan, you all. Ut guarantee they will happen. If they happen, they will uncover flaws. For a company striving to build insecure software, these "inspections" can be disastrous to corporate policy.

This is a tongue-in-cheek look at the most common mistakes companies take which result in insecure software. Building secure software is relatively simple, requires little up-front effort, and helps your company stand apart from the crowd of competitors. No company sets out with the goal of building insecure software, but a combination of inexperience, short delivery cycles and rapidly changing regulatory and threat environments can overwhelm even the best team. If your team needs expertise and help, reach out to Caliber Security Partners. We can come in and help you--our approach is to partner with you to build security best practices into your specific workflow (agile or waterfall). We can provide training, strategic advice, and security services to ensure your applications are increasingly secure.

John Overbaugh is Managing Director for Security Services at Caliber Security (http://www.calibersecurity.com)

How Difficult is it, Really?

I’ve been using an easier version of my coding question lately, because candidates have struggled so much. First I moved it from C to C# (or Java, if candidates only have a java background). Then I simplified it, a lot. The problem is simple: reverse a string using no outside libraries. This was an introductory-level when I interviewed at Microsoft but now it seems to be advanced!

I’ve had candidates waste 40, 50 lines of code answering this. They usually don’t answer the question at all (they won’t write the full function with signature, or they reverse any words w/o reversing the characters, etc.).

I tried it again last night against .NET 3.x—I wanted to make sure I wasn’t expecting too much--you know, maybe programming has changed while I’ve been in meetings! ;).

I ended up with a small challenge (converting my char[] so it returned a string—kept returning the object type), but other than that, this went really well. 15 lines of code, including curly braces and the step to convert from the input string into a char[] (no error handling; have to get to that next)

Is the question too difficult? Wanna take a stab? Can you beat 15 lines, without using string.Reverse()?

Running MSTest Standalone

It’s been a very long time since I posted on this blog – I’ve been quite busy with work as well as writing articles for http://www.searchsoftwarequality.com (head over and check out my tips and Expert Answers).

I stumbled across this today—how-to guide to running MS Test standalone. http://www.shunra.com/shunrablog/index.php/2009/04/23/running-mstest-without-visual-studio/

Full disclosure, during my last stint at Microsoft, I worked on this internally. However, I never disclosed how to do it. I do not know Shunra and I honor my non-disclosure to the fullest extent.

At the same time, I’m thrilled. MSTest is a great product and I’d really love it if MS produced a standalone version. According to this post by an MSFT employee, there’s a lot of discussion around it:

this is one of the things on a higher priorities that we are considering for a future release though this is yet being worked out as such there if no formal statement. I am pushing for this & may have a update in a couple months. http://social.msdn.microsoft.com/forums/en-US/vststest/thread/2897fb68-ef48-4941-a49e-fe8cb1b5aced/

So who knows, maybe we’ll see something soon!

Blitz Blog: Quality Assurance Through Code Analysis

Today I read through a Parasoft whitepaper published on searchsoftwarequality.com, and I found it to be a great approach to static code analysis.

FULL DISCLOSURE: I write articles and am a “Software Testing Expert” for searchsoftwarequality.com. However, I do not blog positively if I don’t believe in the posting.

Parasoft is the manufacturer of an application security static code analysis tool. Of course, the white paper’s intention is to sell copies of their tool. Can’t fault them for 1) believing in their product and 2) wanting to pay the bills.

What I really like about this article is the approach they take to SCA. They are not pushing it as the end-all, be-all of code quality. They are very realistic about SCA, in fact, stating that it’s often over-used and, once over-used, ignored. Companies implementing SCA must be careful about it—don’t enable a rule unless you really want to enforce it.

At the same time, they make a strong point about the value of SCA. It can really help a team drive quality upstream. Some policies an engineering team might want to use, for example, contribute to code readability while other contribute to security (dynamically-built SQL statements vs. parameterized queries anyone?).

As an Agile engineer, I do take issue with their heavy-handed ‘management enforcement’ method. Agile teams need to adopt policies as needed. Cross-company Agile team representatives might establish company-wide policies and enforcement, but the Agile team itself should arrive at the bulk of the policy definitions.

One thing I like to see is the implementation of SCA directly in the build process – ie, no build if the code fails with errors, and a team-wide email on warnings. This is the best way to enforce policies (but teams need to be selective about policies, so they don’t overwhelm or ‘over-stay their welcome’).

Anyhow, blitz blog. Highly recommended reading!

http://go.techtarget.com/r/6673725/7930283/1

Technorati Tags: quality assurance,software testing,qa,security

Oracle Owns the Stack

You’ve probably already heard that Oracle has acquired Sun Microsystems. It’s one big, happy, expensive enterprise systems family! Personally, I think this is not a good thing—it hampers competition. Oracle and Java already have a stranglehold on the IT space, and this merger just tightens the binds.

I have worked a total of 12 years at Microsoft, with two years in IT at other companies, which were both very big Oracle companies. I worked at Circuit City in the Oracle Retail implementation, and I worked at the LDS Church where most everything is running in Java on AIX. With my two years of experience, after working in Microsoft technologies, I have decided Oracle is overpriced, overhyped software. Java I could take or leave, but I firmly believe Oracle sells too little for the money.

Here’s the deal… Oracle sells their hardware and their software at astronomical prices. I mean, seriously… The hardware is expensive. The OS can often be open source, but it still requires people to manage it. If you add up the hardware, DB and other proprietary software, and the management software you’ve sunk a ton more money into than if you’d bought from the ‘Evil Empire’.

On top of that, I do not believe Oracle sells decent products. SQL is OK, but Oracle Retail? It’s a mish-mash of third-party acquisitions, none of which really share a common language or data format. And they bundle it all together and say “It’s Oracle – it’s enterprise quality” and people believe it. As a QA manager, I was appalled. For instance, I could NOT get the Oracle account rep on-site for Circuit to tell me what level of security testing the product had undergone. He told me that was proprietary information which he could not share. So we were investing millions in his software, and we didn’t have the right to know if it was secure? Another example: we tried for weeks (I paid three IBM consultants nearly $600 an hour for six weeks) to automate one of Oracle Retail’s components. The entire time, the Oracle rep was in our status meetings listening to us report blocked, unsuccessful, struggling… Never once did he peep up, until I finally asked how they automate regression testing. At first, he tried to evade with the same “that’s proprietary information” response. When he finally realized I wasn’t going to drop the issue, he admitted they didn’t automate anything in that area. What?? What kind of company watches a customer throw thousands (tens of thousands) of dollars down the drain, all the while knowing the effort is futile?

In my role as QA Engineer at the LDS Church, I was surprised to hear people tell me they would not deploy Microsoft products in the public-facing network segment because Microsoft controls the entire stack, and a security exploit in one layer of the stack meant the entire stack was at risk. ??? From a technology point of view, the opinion makes no sense. Ironically, these were the same people who approved of and supported internal development of security technology, when Microsoft had an existing product on the market (and deployed at the LDS Church). With Oracle now owning Sun, will that answer have to change?

So in a recent guest posting on HISTalk, Orland Portale (former GM, Global Health Industry) spouts on and on about how good this acquisition is. To me the nail in the coffin is the statement that Oracle will begin creating “tightly bundled system stacks which incorporate hardware and software components. Oracle will now have all layers of the systems stack under its umbrella, including the storage, server, operating system, programming language, database, Web services, etc.”

In recent years, Oracle has been snapping up enterprise solutions left and right. They own the entire retail suite. They bought BEA, one of the last independent web providers. They recently purchased MySQL and have control of it. At what point will all the “Evil Empire” opponents realize there’s a newer, much larger empire out there – and it controls all the software they deployed because they wanted to stay away from Microsoft technologies?

I know… Long rant about this. I admit I’m a Microsoft bigot. Except for one product (SMS, or System Center Cofiguration Manager), every enterprise server product I have deployed has just, well, worked! And been reliable and stable. So my bigotry is based on my personal experience. It doesn’t take a PhD to deploy MS software, it works well together, and it’s got great uptime. And the price is approachable, too.

Soon I think it’ll become obvious: Microsoft is the underdog here. Fight back, stop the Evil Empire. Buy Microsoft!

Tenants of a Software Testing Team

If you had the chance to write out the tenants (unbreakable ground rules) by which your quality assurance team lives, what would they be? Here are some I’ve been thinking of:

• We partner actively in quality-first development, by participating in the entire SDLC and by contributing tools, process, and time to the development activity.
• We do not and cannot ‘test in quality’. We test to validate requirements, discover missing or inaccurate requirements and implementation, and to expose defects.
• We use tools and process to discover defects, validate functionality, and improve quality. Not to use tools and process.
• Secure software is a top priority—we protect our users’ privacy as well as our applications reliability.

What about you? Do you have other tenants on your team?

Technorati Tags: quality assurance,qa,software testing,engineering,leadership

Blitz Blog: John Glaser on the Healthy IT Org

Departing from my quality-focused blog postings for a while (software testing rules, but hey – sometimes there’s good info elsewhere too), here’s a pointer to something you need to read!

John Glazer is a CIO and contributor to HIS talk (THE blog for healthcare IT). He captures the essence of a healthy IT org so well, it’s a must-read. And it is quick!

http://histalk2.com/2009/04/13/being-john-glaser-41409/

Technorati Tags: quality assurance,qa,testing,software testing