Your bad code is mucking up my good code

Just a couple of years ago, a whole bunch of U.S. homeowners in the Deep South began suffering from health issues, corroded wiring, malfunctioning heat and air conditioning, foul odors, and blackened fixtures. It turns out that while their houses were solidly designed and built, EXCEPT for the inclusion of toxic drywall originating in another country. Fixing these problems can cost a resident as much as it cost to build the house in the first place, because it involves removal AND replacement of the drywall and all the affected components, plus in many cases the residents have to live elsewhere during this process.

The ugliness has been further complicated by the fact that the manufacturers of this bad drywall were not subject to U.S. laws, although there have been many settlements. A few simple-minded xenophobes commented that this is what happens when people buy foreign goods. This ignores the fact that there are a lot of quality foreign goods available in and from just about every country, and there’s no guarantee that every product made in one’s own country is by default a quality product.

An awful lot of code powering an awful lot of business apps, just like these houses, are partially comprised of third party pieces, foreign or domestic. Ideally, you would test your software, including all those third party pieces, top to bottom. For example, you want to ensure that your software won’t be used against you to cough up proprietary data. And maybe the pieces of code you create are dandy, but you’re including third party libraries or custom code. And way too many third parties either don’t teach their people to code securely, or they give their junior programmers some desktop source code testing tools and think this is sufficient to guarantee safe code.

And that’s the kind of thing that software testing tools are built to deal with. But being that this is an identity blog, let’s concentrate on that aspect.

First off, by applying tight policies on provisioning and access, you (help) ensure that only the correct accounts can execute necessary functions within your critical business apps. It’s that first line of barbed wire, weeding out the bad guys from getting to the platform from which they might launch attacks. One of the places that’s most common for launching, for example, SQL injection attacks is login screens. Proper authentication validation can prevent such an attack at the outset. Take that logic away from the business apps, and put it where it belongs, in a security layer. If the bad guy doesn’t get in at that point, he loses a whole lot of other opportunities to launch other such attacks from within a session that looks to the system like a legit one.

Second, if the bad guy does manage to get inside the front door, that back end security is one of your safety nets. This means securing the data. This is why Oracle provides Database Vault and Audit Vault, to know who’s doing what, and even allowing or disallowing certain functions, based on realms, roles, and individual identities.

By applying these layers of security, we can mitigate some of the risk of faulty code, whether it’s third party or homegrown. Even if you build completely secure code to start with, you still need to secure it from misuse, and that’s a heck of a lot easier than swapping out half your house.

Comments

[Lawrence]

I look forward to the lecture tour!