While speaking at a conference out west an interested attendee challenged me: “You said I should make my security standards as specific as possible, but the other speaker said, ‘Keep them general’, what gives?” This type of exchange happens all too often in the software security space these days. I could do a piece on that alone, but instead, I’ll address the challenge.

The confusion stems from two competing goals driving standards creation: 1) providing useful security know-how that benefits developers and 2) obtaining ‘coverage’ of all the security concepts, technology stacks, and development/deployment platforms your organization uses. To be useful to developers–to truly change the way they behave when “Their butt hits the seat in front of their compiler”—one has to speak their language. Developers speak and write code. Documents like security policy, tend to be written by Corporate Security, or worse: lawyers. These groups speak and write legalese. There’s a big difference and it’s easily detected: one usually comes in 12pt. Courier.

Your objective: answering questions about how to do things right for developers by showing them the right way… while leaving enough flexibility and room in the guidance for them to remain creative and solve the business problems their application was intended to.

Writing technology-specific guidance engages Security Architects in helping directly solve Developer problems. Rather than specifying “Do not allow direct access to Servlets by name” (a decent agnostic standard, when used in concert with others) show them how:
——
Using Struts, map an impossible-to-assign role, such as noaccess to every Servlet but one–a single front controller–that mediates access to your other Action Servlets like this:

 <web-resource-collection>
   <web-resource-name>Application</web-resource-name>
              <url-pattern>/functionality</url-pattern>
       </web-resource-collection>
  <auth-constraint>
   <role-name>noaccess</role-name>
  </auth-constraint>
 </security-constraint>
 <login-config>
  <auth-method>DIGEST</auth-method>
 </login-config>
 <security-role>
  <role-name>noaccess</role-name>
 </security-role>

Place all Action Servlets in a single directory, for ease of maintenance (/functionality in the example above). Demand authentication prior to access to the single front controller and delegate actions from that Servlet.
——

Alternatives may be necessary. For instance, while the standard prescribes lumping functionality in one directory–that may not be possible. For those cases, the standard should describe how extension based url-patterns can aid in casting the broadest net possible.

Standards, at this level, should always state a preference however. The worst offense of failing to do so is nearly every J2EE book’s discussion of both declarative and programmatic means of authorization without indicating which should be used when.

Next week I’ll move on and discuss detailed, technology-specific security guidance in more detail, but first I would like to recognize the value less specific guidance provides. Detailed, technology-specific guidance requires significant time and effort to produce. Such guidance is perishable and becomes useless as you upgrade or update your technology stack. Technology agnostic guidance, or guidance kept at the level of security concepts insulates you a bit more. Organizations should certainly start with this level of guidance, getting coverage over the broad array of security topics needed to educate their developers before diving down a rabbit hole and writing technology-specific guidance.

In other words, one level of guidance does not replace the other. Instead, less specific guidance serves as safety net underneath the more specific, catching inquiring minds when the specific guidance hasn’t been written yet or when it doesn’t apply (as often happens when a team faces constraints like deploying an old version of Tomcat).

I hope, however, that in the meantime I’ve shown an example of how being technology-specific, code-centric, and detailed about standards can engage security folk in development, engage Developers in their own language, and actually push projects forward more quickly by making hard security decisions for them. This is just one of the activities your Security Architects can undertake when they parachute into development teams… a concept I introduced in my blog entry on research in the 50’s.

Technorati Tags: software security

I’d like to give a slightly different perspective on a topic John Steven talked about a few weeks ago (“Keeping up with the Jones’ Security Initiatives”).

Be a goose; don’t spend “10%” just because it’s a popular number.

I spent the first four years of my career, in the early 1980s, in the Air Force. I worked as a systems programmer in the Pentagon and had direct responsibility for system security (Go Multics!). This was a timesharing mainframe with directly connected VT100 terminals in secure locations, so threat was fairly well understood. It was all about availability then, even though security was paramount. If the system was down, heads rolled. On the other hand, if some MLS control prevented the general from doing something he thought would be cool, well that was just tough. No one ever asked me, “Do we have the right level of security?”; it was always some question about specific vulnerabilities and how to remediate each one on a case-by-case basis. These were ducks.

As a defense contractor employee, I worked with dozens of classified and unclassified systems, some on the burgeoning Internet and some not. I performed virtually every kind of security review, pen test, IV&V, and tiger team you can imagine. No one ever asked me, “Do we have the right level of security?”; it was always some question about specific vulnerabilities and how to remediate each one on a case-by-case basis. These were ducks, too.

After 12 years in the commercial world, I’ve seen or worked with virtually every information security technology. And, although I gave up software development a long time ago and pen testing more recently, I still try to keep current. I’ve worked with hundred of organizations on thousands of security issues. In my experience, only in the last few years have some organizations begun to look past the individual assessment results and ask about their level of security and its overall appropriateness (first in financial services and later in other public companies). At last, a goose or two.

However, the vast majority are asking about it solely in relation to their peers. These organizations are not asking, “Do we have the right level of security?”, they’re asking “Do we have about the same amount of security as everyone else, good or bad?”

This is wrong thinking and here are two reasons why it bothers me.

The first is the large number of organizations that are insulted at the mere insinuation that I can “know them” even if I have years of experience and I’ve worked with other firms in their vertical, or even with other business units in the same company!

The second is that they’re right. You can’t really know a given organization just because you’ve worked with its competitors. I can understand implicitly the risk associated with their transaction processing systems, with their SOA framework, with their Internet-facing systems, with their overall approach to security, and so on. On the other hand, I really have to work with them to understand what drives them, what is the tone at the top, what decision will they make when push comes to shove, their risk appetite, where they will cut IT dollars first, whether they really are trying to act strategically as opposed to simply having a 3-year plan of tactical initiatives, and so on.

So, why would these organizations think that I can’t know them by working with their competitors, think they can know something about themselves by comparing furlongs per fortnight of security spending with their competitors?

Here’s are two admittedly loosely related stories:

I did my taxes a few weeks ago and was told by the application the percentage of tax-paying Americans who were “like me” in income and tax burden, with no real additional information. Were these families or single filers? Did we have similar kinds of deductions? Did we have the same cost of living? What did these comparisons mean? Duck or goose?

I went to my doctor recently and was told the percentage of Americans whose weight, cholesterol, and related items were similar to mine. Here, however, I was also told how each of these items factored into overall health. In gruesome detail, I was told about various mortality rates, stroke rates, heart attack rates, cancer rates, and so on until I simply wanted to nibble lettuce for lunch and stay out of the sun forever. But, still, did these other people have my heritage, my work and exercise habits, my eating habits, or anything else that made them like me? Again, duck or goose?

In the information security space, we’ve had (mostly by the analysts and the press) huge discussions about whether 10% of the total IT budget was the right amount to be spending on security. According to Forrester, that number has hovered in the 7.5%-9% range for the past few years. That’s good to know because it gives us a general guideline (which is all we can have in the absence of any real actuarial security failure data, but that’s a rant for another time). However, in multi-billion dollar corporations where a 1% difference in IT security spending could equal the annual revenue of many of small security firms, what does this percentage really mean? If one organization consistently spends significantly more than it’s competitors on hardware, data centers, and related IT items, should it necessarily also be spending more on IT security?

I realize these percentages are just guidelines, but they’re the kind of guideline a sharp litigator will latch on to. Remember that no one wants to be the odd man out. No organization wants to have to explain to some regulatory or law enforcement organization the possibly coincidental facts that it suffered a security breach and was also spending somewhat less on IT security than the average for their industry, or country, or whatever.

So, much like I am, I’m sure you’re wondering whether I have a point or whether I’m simply writing this at 4am because my allergies are kicking Claritin’s butt. My long-winded point is simple: We’re all the goose. Every single organization has its idiosyncrasies that make the 10% rule of thumb somewhat less than useful for anything other than selling research reports.

Organizations should spend as required to adjust risk to acceptable levels and realize that not all of that spending will be in IT security dollars. By and large, IT security doesn’t pay for governance, it doesn’t pay for attitude, it doesn’t pay for commitment for excellence. With these things being paid for elsewhere, the IT security budget may be lower and likely result in lower risk (i.e., improved “security”).

We shouldn’t dwell on the size of this ratio; we should worry about the environment in which it exists. A spend of 10% in an immature, ad hoc, no-vision company, probably means they’ve spent the entire 10% on point security solutions ranging from desktop AV to firewalls to IDS and so on. Which means they spent little or nothing on policy, training, proper tools for developers and testers, and so on. Which means they are an accident waiting to happen - 10% not withstanding.

On the other hand, a lower percentage spent within a mature organization that also spends to foster and reward good thinking will almost certainly produce lower risk. Sure, mistakes will still make it into production and there will be problems, but there will be much fewer of them, they will likely be of reduced consequence because the organization knew to look for the big problems and also had effective response capabilities, and the organization will learn and not make those mistakes again. They will make new mistakes, but everyone does.

Be a proud goose. Organizations must not be afraid to use good governance, good training, and good process to their corporate and competitive advantage. If you do good strategic things, you will achieve better security with a smaller capital outlay that doesn’t all come from IT security. Organizations must be comfortable with their risk management story, and their efficient spending, and be able to tell it to the market, to customers, to regulators, and, if necessary, to juries.

Technorati Tags: governance

(with apologies for complete lack of artistic merit)

feng shui governance
plan, influence, and conduct
policy for all

from boardroom to bits
everyone get on board
a single train forward

a balanced approach
harmonious existence
with stakeholders all

set tone at the top
the key of transparency
all must understand

solving all problems
a terrible goal to bear
just cut barriers

how to change things now
like escape from klein bottle
reverse of trip in

business objectives
publicly painted for all
now all can align

our key resources
named, owned, prioritized, staffed
requirements sketched

cooperation
embrace management’s vision
collaboration

internal control
believable proof for all
this is a good thing

need innovation
old way causes much sadness
delightful change now

who must get what done
true responsibility
good authority

what must get done when
relate business to people
and goal them quite well

when must it get done
everything can’t be first
true order defined

where does it happen
are all things prepared for it
measure twice, cut once

how to accomplish
training, coaching, mentoring
lead by example

why is it crucial
all must recite the drivers
to you and to me

it’s about people
enable them to succeed
show you care about them

expect and inspect
balanced scorecard works for most
dashboards are fun, too

you are not there yet
a continuous journey
goals ever-changing

quite learned you are
required knowledge deep inside
express yourself now

P.S. Although I though I was the first to use “feng shui governance” as a term, I noticed that there was a single hit in Google (a three-word GoogleWhack!) used by a Mr. Foldvary back in 1999 in a somewhat different context.

Technorati Tags: governance, doggerel

Cigital is in the business of making software secure, often by telling our clients precisely how and why their software is not secure. There are an almost infinite number of ways to be vulnerable so it should be no surprise that we rarely find the perfect system. I’m tempted to say never, but I’d have to check around on that. We have a saying in the office that the only truly secure system is one that is buried underground with no wires in or out and no users.

Some of our clients, though, are shocked and more than a little annoyed when our assessment is critical. A top level manager may express gratitude when we confirm his gut feeling, but the middle manager with direct responsibility for the system is often embarrassed and defensive, and the guys in the trenches are downright pissed. That’s too bad. We aren’t top level managers. We are trench warriors ourselves. We truly appreciate how very difficult it is to write excellent code—code that does what it is supposed to do, code that works fast, code that works reliably in a production environment, code that is maintainable and code that is secure.

I once lead a development team that produced some code that managed some highly visible and regulated financial transactions. The code had to be 100% free of errors as there were many critics with deep pockets, political connections, and dozens of lawyers who wanted it to fail. The client wisely hired an independent (end excellent) team to perform extensive IV&V at the test level and the code level. The team showed up in my office where I gave them all the documentation, all of the test results and test code, and unfettered access to my pre-production staging area. I figured they were just code shmoes like me, just doing their job, so I tried to be nice. Their attitude though was that of an IRS auditor on the trail of a bootlegger. One day I walked in and gave them a couple of boxes of Girl Scout cookies from my troop (Thin Mints, I believe). They turned down the cookies and told me that it was completely inappropriate of me to offer them anything of that sort. I lost it. I screamed “They’re not bribes, they’re goddamned cookies. Eat the ——- cookies!” They were so shocked they all instantly grabbed one and ate it very quickly. It was hilarious, and we eventually had a laugh over it.

At Cigital we don’t want to be like those fellows. We love smart coders—they are our kind of guys. Let the guys in sales play golf with the bosses. We would rather drink beer (or Mountain Dew) with the folks on the midnight pizza shift. At root though, we do review other peoples’ work, and sometimes the auditor mentality takes over. One of the best guys at Cigital recently took on an audit gig. He told his manager that he wanted to keep the report secret until the end of the project, so he could produce a bug-rich audit report. I suppose the idea was to show how smart he is and we are. His sage manager told him to cut it out and share the findings as they emerged. The result was that we produced a long bug list, but noted in the final report that almost everything had already been addressed. That’s a good outcome for our client and a good one for us—we got another gig.

Writing good code is real hard, and the smart guys who do it are the heroes of our business. We love you guys, but we sometimes do have tell your that your baby is ugly and we’ll go beyond that to describe every deformity, wart and blemish in lurid detail. Understand, though, that we, like you, want that ugly baby to grown up into a runway model.

Technorati Tags: governance, regulation, software security

The PCAOB is introducing new guidance to help lower the overall cost and, presumably, increase the effectiveness of SOX 404 audits. It needs to use this opportunity to help fix some root causes, not just tell us how to find more symptoms.

This past December, the PCAOB announced that it would propose for public comment a “new standard on auditing internal control…designed to focus the auditor on the most important matters, increasing the likelihood that material weaknesses will be found…” The proposal itself can be found at http://www.pcaobus.org/Rules/Docket_021/2006-12-19_Release_No._2006-007.pdf.

Starting on page 93 of the document, there is a section on “Benchmarking of Automated Controls.” It includes guidance like “Entirely automated application controls are generally not subject to breakdowns due to human failure,” which is clearly not true since bad input makes functional application security controls fail all the time. Telling auditors that automated application controls automatically get a gold star is not a step in the right direction.

It does go on to suggest that the benchmarking strategy take into account the importance of the effect of related files, tables, data, and parameters on the consistent and effective functioning of the automated application. That’s a good thing.

The document then suggests that “If general controls over program changes, access to programs, and computer operations are effective and continue to be tested, and if the auditor verifies that the automated application control has not changed since the auditor established a baseline (i.e., last tested the application control), the auditor may conclude that the automated application control continues to be effective without repeating the prior year’s specific tests of the operation of the automated application control.”

So, never mind that new attacks are discovered with unnerving frequency and that perfectly good code can suddenly become not so great (think crypto algorithms), the apparent recommendation is that if you didn’t or couldn’t poke hard enough to break it over some time period, then it’s okay to skip it later. Approaches like this where we’re considering only functional changes and not testing skill and depth can’t be effective.

How many times has someone walked up and spotted a problem you failed to notice time and time again. As organizations periodically change auditing firms, expect huge increases in reported problems.

The proposed guidance gives the following factors to use when deciding to use benchmarking:

• The extent to which the application control can be matched to a defined program within an application;
• The extent to which the application is stable (i.e., there are few changes from period to period); and
• The availability and reliability of a report of the compilation dates of the programs placed in production. (This information may be used as evidence that controls within the program have not changed.)

This wording is still neglecting changes on the threat side of the equation. Just as many castles were considered impregnable until about five seconds before the first cannonball hit, many lines of code were considered secure right up to the point where the breach story appeared in the newspaper.

The guidance gives the following factors to use when deciding whether to reestablish the benchmarking baseline:

• The effectiveness of the IT control environment, including controls over application and system software acquisition and maintenance, access controls and computer operations;
• The auditor’s understanding of the nature of changes, if any, on the specific programs that contain the controls;
• The nature and timing of other related tests;
• The consequences of errors associated with the application control that was benchmarked; and
• Whether the control is sensitive to other business factors that may have changed. For example, an automated control may have been designed with the assumption that only positive amounts will exist in a file. Such a control would no longer be effective if negative amounts (credits) begin to be posted to the account.

Okay, so if I know that most auditors and organizations use COSO as a governance model, and COBIT 4 to interpret COSO to arrive some IT control objectives, and I consider AI2, Acquire and maintain application software, important to my environment, then I might understand what “controls over application and system software acquisition and maintenance” means above. And, I might even read COBIT and see AI2.4, Application Security and Availability, which states “Address application security and availability requirements in response to identified risks, in line with data classification, the organization’s information security architecture and risk profile. Issues to consider include access rights and privilege management, protection of sensitive information at all stages, authentication and transaction integrity, and automatic recovery.” Oh wait, I only need security software, not software security. Sigh. Another opportunity missed.

There is a need here for any words that introduce something like the following:

The customer may have written their own software that is directly used in the financial reporting process and you, the auditor, should be aware not only of the software’s functional controls (e.g., I&A, encryption, entitlements), but you must also accrue confidence that their internal development practices and testing are sufficient to produce quality software that has at least some capability to protect itself from attack even in the event of catastrophic failures other general and IT security controls being considered as part of this SOX audit. While security software may comprise the majority of IT security controls, software security is the property that gives us confidence in their continued successful operation even in the certainty of ongoing attack. You must use a risk-based approach to accruing confidence, focusing on relevant factors that have a material effect on the software’s ability to meet business objectives even in an overtly hostile environment.

Now we’re thinking more about the problem and less about the symptoms.

Technorati Tags: software security