I am strong advocate of service oriented architectures. I have seen them work—not in theory, not in demonstration, but in real, deployed, mission critical applications. In sitting down to write this blog entry I was going to do yet another “SOA - Hype vs. Reality” essay. I’ve written a lot of these over the past four or five years, and, frankly, theses pieces are getting boring to write and boring to read. Its just not a burning issue — the next generation architecture debate is over, and SOA won.

Sure, most of what you see when you walk into a big IT shop is still monolithic applications, but those are echoes of IT history—dead men walking. SOA won because it is a natural evolution and logical extension of the way we have been building systems since Grace Hopper showed us the light. Our first programs looked monolithic, but only on the surface. We learned that good practice requires us to decompose our programs into procedures, subroutines, (or whatnot depending on the language) that had limited functionality with well-defined interfaces—nothing too large to fit in the space between our ears. Code reuse as the Holy Grail.

SOA is just the extension of good programming practice except that high bandwidth, reliable, standards-based networks and emergent standards for things like message transport, service registration and service invocation mean that our systems need not operate in a single memory space. The acronym SOA may not survive. Software sales dudes always come up with new names to sell a polished up version of the same-old, same-old, but service-oriented architecture and, more importantly, service-oriented architecting is here to stay; its centrality in future systems is as inevitable as the sun rising in the east.

With that rant out of the way, what I want to say here is that there are unique security issues related to security. I plan to discuss these in forthcoming blog entries, but I have a meeting today with the Ettienne Reinecke, CTO of Dimension Data, one of the best networking companies in the business. I have been thinking hard about how the guys like him play in SOA beyond giving us reliable pipes. Let me share my thoughts.

Networks work really well—software not so well. Why? I suggest that the success of the networks lies in three factors—componentization, standardization and that management. Networks are not monolithic. They are composed of lots of individual pieces, each with a well-defined function (sound like SOA?). The performance and interfaces of each component type are very well-defined by standards. This means that different components can be integrated with moderate ease and some reasonable expectation that they will work together. It also means that the people who develop the components can continue to refine their designs—to polish them until they are sparkle, making each generation, faster, better and cheaper—as long as they keep the interface constant.

Finally, the network guys assume that the network isn’t going to work. They assume that components will break, so they instrument the network to monitor its performance and they watch it carefully. Good network engineers also design for graceful degradation—the ability to lose performance in increments rather than catastrophically (think escalators vs. elevators). We on the software side can learn from this. The presumption of fallibility and the capacity for graceful degradation are alien concepts in the software world. They shouldn’t be.

In moving to SOA, we are componentizing. In adopting web-service standards we are standardizing, though our standards are much less mature than those for networks. Good for us—we have to two of the lessons down—componentization and standardization.

Let’s take the final step, and build our SOAs with the assumption that they will fail (a safe assumption) and engineer-in monitoring and the capacity for graceful degradation from the beginning. We can “ping” network components to see if they are alive, query their state, test them and change their state during operation. We should be doing this for SOA services. Ultimately, system operators should be able to look at panels like those now used for network operations, showing in color codes the status of each service. They should be able to detect problems and fix them on the fly.

Essentially, as we move towards SOA we are shifting from thinking of our systems as discrete entities to thinking of a computing ecosystem that runs 24 hours a day, 365.2564 days per year (more or less). This model is completely unnecessary for a simple program that does one thing, and only runs once in a while, but these are becoming an endangered species.

The trend in IT has always been towards greater integration. The data from one program feeds into the next, and the next…and the next. We can think of a data store as the DMZ between two applications or we can think of it as a cache in a larger system. The boundaries between systems are often arbitrary and are often simple reflections of org-chart boundaries rather than computational or business logic. At the level of the enterprise, we are evolving towards a more comprehensive view, beginning with simple shared services like database and directory, but moving, inexorably and inevitably towards shared functionality.

The network engineers have already made this transition. We should lean from them and relentlessly componentize, standardize and manage.

Technorati Tags: software security

If I were to say penetration testing, what would you expect? After conversations with lots of colleagues and friends it’s become fairly clear to me that the term is massively overloaded. It actually got me thinking about the evolution of pen-testing over the last several years. And I’m not going to preach from the you-need-design-and-code-review-too pulpit. I’m just gonna talk about the innards of the pen-test itself (breaking a running system).

The old-school notion of a pen-test was one where you’d hire a bunch of l33+ h4×0r5 and turn them loose on a system to see what they are able to bust. The general idea here was to simulate a real-world attack scenario (black-box pen-test). Given adequate time, Cheetos^® and Red Bull^® you’ll probably be left with some findings that are interesting. But take a closer look at the breakdown of how those testers spent their time. Those guys likely spent a ton of their time trying to figure out how the app works, trolling for non-obvious interfaces and partially reverse-engineering the logic of the app. When you’re paying by the hour, this is bad news since they didn’t spend as much time as they could have in actually trying to break the app (they spent a bunch in just getting their arms around it.)

Evolving from these obvious limitations in the completely black-box approach the notion of the “pen-test with code” was born. This was a similar scene, but instead of poking at the running app as much, the testers would go and read code. While the testers are still at arm’s length from the dev team, it’s still better since access to the code gives a truer picture of what’s actually happening under the hood without time spent on reverse engineering. Sometimes, there would even be design docs available which really helped move things along. In the end, this is close to the modern-day version of what many expect when they buy a “pen-test.”

The major weakness of this style of pen-test is that there’s often no business context to ground the direction of the testing (on which aspects of the system you concentrate) or to baseline the value of the findings (to the company using the app, what do the discovered exploits really mean?) Some pen-testers are starting to bridge the technical-to-business gap, but they’re definitely in the minority. This step in the advancement of the pen-test is definitely a step in the right direction since it focuses the testers on generating and prioritizing findings that show demonstrable impact to your core business (as opposed to sheets of meaningless XSS vulns that are all prioritized “high” since XSS is bad.) The pen-tester gets to concentrate on breaking business logic in your application and scheming about combinations of technical vulns that lead to an interesting business problem. You’ll still get all the technical vulns, they’ll just be low priority if they can’t directly contribute to a bigger problem. Since this all plays into making risk management decisions, I call this style of white-box pen-testing the “risk-based pen-test.”

If you’re using pen-test today, you really want as close to a risk-based pen-test as you can get. Although I have heard a few reasons why you might not:

• “I don’t have access to code or design docs.” I hear this reason all the time as justification for why a black-box approach is used. In the end, even if you don’t have code, someone has gotta know something about how the application actually works. Even if it’s only from a user or sysadmin perspective, it goes miles to setting the testers off in the right direction. Find those people and link them up with the pen-testers! And business risk mapping is still possible even without code (but you’ll probably need at least ad hoc design info).
• “I use black-box pen-test nowadays as a way to simulate real-world attacks.” This notion is just off-base due, perhaps, to the lack of understanding about real-world attacks. Yes, the people “in the wild” that might attack you will have a similar skill-set to your pen-testers. The kicker is that the time available to an outside attacker is virtually infinite compared to that of a for-hire pen-tester. When it comes down to exploiting software often it’s just a matter of how much time you spend bashing your head against the problem. Outsiders can spend 2 hours a day for 6 months working on getting a single exploit working. Your pen-testers have 8 hours a day for a week to find lots of impressive results. Thus, cheat the problem by giving the pen-testers all the info you have.

In any case, let’s get back to talking about that notion of the risk-based pen-test. When I think about the requisite skills to complete that job I see many similarities to what QA folks do on a routine basis. Foremost, the QA testers will already know the application components and UIs. They should know the business value of the app and in many cases they’ll also know how the business logic of the app is supposed to work. And also, they are routinely asked to assess the specific business impact of problems in the application (they do it every time they open a bug and assign a priority.) That’s a huge advantage over someone from the “outside” coming into a pen-test engagement. Now what about differences? The biggest red-flag is that the QA people aren’t trained to attack applications to find security flaws. That’s a big disadvantage since you need those skills in order to be even remotely effective at a pen-test. But do keep in mind, QA folks are very much trained to break applications in general (it is, in fact, their job.)

So where are we going with this? Simple: let’s give the pen-testing responsibility to the QA team. They’ve already got a leg-up since they know the application. To counter the point about them not being trained in security attacks employ two simple techniques: tools and training. Some of the automated pen-testing tools out there are really great now. They’re basically extremely potent packages of electronic subject-matter expertise. Now, I would never advocate just buying a tool and hitting the “go” button and calling the job done (you don’t get very good results at all this way.) Enter the training. The automated pen-testing tools, in many ways, are very similar to other types of tools in a QA tester’s belt. They run a series of attack test-cases and report vulnerabilities when a test fails (this is a massive oversimplification of what they’re doing under the hood, but in terms of usability, the analogy holds.) So, train the QA testers on effectively using those tools. Teach them about how to feed application-specific details to the tools to make sure your coverage is high and ensure the results are more accurate.

Further, teach them about the classic notion of security testing (starting with requirements and deriving test-cases to ensure that functional requirements are implemented securely) and show them how to automate it with the tooling. In fact, that’s where this is all ending up: a risk-based security test with a wide blast-radius for getting the bulk of the benefit of a pen-test. It’s cheaper in the long-run (front-loaded cost for buying tools and building the internal skill vs. repeated, indefinite fixed-price cost.) In terms of effectiveness vs. an external pen-test, it’s definitely on the positive side of the 80%-20% rule (and all the things you might miss in that 20% will likely be caught by code review or architecture analysis.) It’s even “faster” in the sense that an organization could move through each assessment more quickly, thus enabling more assessments within a given timeframe.

In summary, I see the future of pen-testing as a push toward QA environments. Since the notion of a code review and architecture review are becoming more mainstream, this makes sense. Why continue to spend a lot on a service that ultimately should be used as a sanity-check of the running system?

Red Bull^® and Cheetos^® are trademarks of their respective companies.

Technorati Tags: penetration testing, 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

Frequently, those directing software security initiatives ask what others in their space are doing. I believed this was a perfectly reasonable question and answered, dutifully protecting each side’s confidentiality as best as humanly possible. Indeed, this kind of perspective represents one key value Cigital provides to our clients.

Over time my relationship with clients deepened, as did their maturity in software security. Their questions also deepened, getting more specific: “How far down the static analysis tool adoption path are my competitors?” I can’t see any way of answering questions this specific without giving away others’ competitive advantage, potentially exposing them to risk, or violating their trust (not to mention NDAs). Stuck wondering if I would be unable to provide further perspective, I began to question this perspective’s real value:

“Is the Jones family really the goal?” I asked myself. Actually, I’m pretty sure it isn’t. Each organization’s security efforts should grow very differently from one and other. They’ll start at different places, sure. Not only that, but even if you tackle the same problem as your competitor chooses to tackle, the ‘optimal’ approach for each organization differs. Why? Because each IT shop grew up to support their business differently. Metaphorically both you and the Joneses have children—but both sets of children have very different special needs.

Certainly, hallmarks of a good program exist. At this point, I consider organizations behind unless they:

• Conduct source code and architectural reviews of software produce and acquire;
• Leverage a static analysis tool suite in reviews;
• Train developers using hands-on instructor-lead courses;
• Augment training with continuing education;
• Distribute technology-specific security guidance, showing developers proper use of open source toolkits, frameworks, and COTS components;
• Subject applications to penetration testing in production;
• Measure both the vulnerability of software as well as the effectiveness of means by which software is secured.

While not exhaustive, the above list indicates a firm commitment to whitebox analysis. Cigital helps companies deploy the above means, in lock-step with each other, in order to get maximum benefit. Without help though, which measure you focus on next depends your organization. But additionally, how you make each effective will also depend on specifics of your organization. I’ve listed several factors that play into software security initiative decision making:

• Do you build, acquire, or buy most of your deployed software?
• Is your company an IT shop, supporting a business, or a product company?
• How do you characterize the bulk of your developers: Off-shore, out-sourced, contracted, seasoned, new to the field?
• What background do your Security resources possess: Network security, Development, Architecture, Management?
• What languages do you use, primarily, for software development?
• How varied is your development platform and build environment?
• Where do security resources report in the organization?
• Is the organizational culture centralized, one of strong governance? Or, does the organization rely on engineers to direct its efforts?
• What architectural paradigms does your application suite conform to? Are they primarily n-tier, monolithic, client/server, or federated? What messaging, transaction, structural, and behavioral patterns do they implement?
• What assets do the applications protect: functionality, data?

Obviously, when we conduct an organizational assessment we augment the above questions with a wealth of others.

Having explored data the above prompts gather, I suggest organizations build on their strengths rather than attacking weakness head-on. For instance, rather than foisting security analysts on development to do architectural analysis, I suggest teams subscribing to an agile methodology begin by augmenting use cases with misuse/abuse cases. Later, those teams can build towards threat modeling and begin to add elements of architectural analysis into their process of re-factoring. Augmenting a familiar activity always proceeds more smoothly than adding another (perhaps foreign) step. This advice stands in complete opposition to what I commonly give to IT shops with strong central governance: begin conducting architectural risk analysis immediately.

Over time, your security efforts will achieve coverage over prescribed best practices. Playing off your organization’s strengths can keep development more comfortable as it maneuvers to deal with security, often a new objective. If your security group succeeds in rolling out security practices synergistically development will view them as resources, not annoying cops. Ideally development begins to pull security into their efforts—requesting their time proactively because they see the value.

Remember, there’s no one-size-fits-all solution, especially in a discipline as young as software security. What will work best for you depends on the specifics of your organization. So rather than worrying about the Joneses look to understand your own situation better and respond to it in turn.

-jOHN

Technorati Tags: software security

Welcome to Cigital’s brand new software security and software quality blog. That’s right, after ranting and raving in other forums for over a decade, we’ve decided to take it to the Web. Let’s call this blog “Justice League.” We’re glad you’re here.

It’s customary start a blog with administrivia, and this one should be no exception. Justice League will be a joint production of all of the Principal Consultants at Cigital. So, yes, it’s a corporate blog (wah wah waaah) but we promise that it will not suck. We’ll be passing the baton around like a hot potato. “No after you.” “Please, after you.” Somehow I ended up with the potato first.

I guess it’s my job to set the stage and introduce your cast. Many of you know me from my external speaking and writing. I’m Gary McGraw, CTO of Cigital, author of a big pile of books on software security, and host of the Silver Bullet Security Podcast. In my secret other life I am the fiddler for Where’s Aubrey.

Joining me to produce this blog will be <insert drumroll here>:

• Pravir Chandra. Pravir joined the Cigital team from Secure Software where he was Co-Founder and Chief Security Architect. Pravir is best known for his work on CLASP and for running an Operations Security group at AOL. Slightly lesser known is that Pravir was once a research associate at Cigital about a million years ago. In addition to being one of the top minds in the world in software security, Pravir is super nice, brilliant, and loads of fun.
• Scott Matsumoto. The great thing about Scott is that he brings 20 years of hard core commercial development experience to the team. Scott has served as CTO of both Spring Street Networks and Xtremesoft (where he was a co-founder as well). Scott is a seasoned software architect and a database guru. Scott is as self-effacing as he is experienced, but don’t let him fool you—he’s sneaky, clever, patient, and has attained the Buddha calm.
• Sammy Migues. Sammy has a long storied career in security stretching back before I was born (ok, not really). Sammy contributed to the infamous Rainbow Books (thanks, man), helped to invent the concept of software assurance, and has been applying knowledge management techniques to computer security for a decade. Sammy was the Chief Scientist of iDefense and Principal Scientist at Cybertrust before he joined Cigital. Sammy escaped from Louisiana in a similar fashion to my escape from Tennessee-we both found a pair of shoes and slipped across the border.
• Craig Miller. Craig really does have computer science bone fides stretching back to before I was born! In fact, he is the most seasoned technical veteran in the firm. Craig has been Chief Scientist of SAIC, CTO of Proxicom, North American CTO and Global Chief Architect of Dimension Data, and a bunch of other things. Like me, he’s a Dr. of something or other. He’s also a music fanatic, a yarn teller, and a jolly good fellow.
• John Steven. The infamous John Steven (or jS as I call him) has been with Cigital for many years. John is my right hand man, and is one of the main reasons that my job rocks. John’s knowledge of Java goes as deep as the inner workings of the VM and gets as lofty as architectural patterns for MVC’s in J2EE. John is intense, intelligent, and introspective. He also has just a few opinions.

Together, we plan to cover lots of ground in software security and software quality in this blog. We’re hoping for a dialog, so please tell us what you like, call us on the baloney, throw us the occasional bone, and generally enjoy yourself. We aim to have fun with this blog in an open interactive way.

My friends who run blogs—including my girlfriend from high school, all my buds at Fortify Software and my friend Jon Udell (who has been blogging basically forever)—all keep their entries short and personal. We’ll try to emulate them.

For the first few weeks, expect a new post every 2-3 days. First up is John Steven. Hey man, catch the potato…

Technorati Tags: software security