In the last entry, I responded to dashboard initiatives and organizations’ attempt to measure. Examples focused on vulnerability-detection because a lot of software security expenditure has as well.

Some practitioners, as well as software security managers, have realized that a focusing only on uncovering the problem won’t get it fixed. They’ve begun to document secure sample code, construct secure-development frameworks, and even harden existing open-source frameworks in order to make secure application development easier. This trend cuts across those IT shops supporting non-software businesses (such as finance, insurance, gaming, and the like) as well as software vendors. Let’s look at the 2nd surprising finding from SAMM data gathering, as published in Gary’s InformIT article:

8. Secure-by-default frameworks can be very helpful, especially if they are presented as middleware classes (but watch out for an over focus on security “stuff”).

Secure-by-default frameworks for aiding in development are absolutely my favorite part of software security. Not only do they make sense as part of any program, they represent an essential corner-turn from a hopeless attempt to keep developers abreast of what they’re doing wrong to the downward push towards the finish line by helping developers release better software. In 2001, plainly sick of documenting and demonstrating the same vulnerabilities over-and-over again in meetings and reports, I begun to talk about, seek money for, and outline what such a framework might look like for use of Servlets in the Java EE platform. Frankly, sometimes it’s just plain easier to describe how to do something correctly than it is to conceive of pen-tests or static analysis rules that will find all instances of vulnerability, some omission, or an incorrect implementation.

But, I’m not the only one that’s been climbing this hill: A broad range of approaches to constructing such frameworks are visible within my own client base.

Some organizations have taken their cue from what the network and host security guys have done in their own spaces. These software security groups see software security as a mapping between vulnerability and the need for control. This drives two sets of behavior:

With regards to the software they build, these organizations tend to strive towards having some central engineering team (or a particular development group) provide a ’security control’ that they can plug in for each vulnerability. This has had two effects in my experience:

1. The ’security framework’ ends up as an amalgam of functions designed in very point-solution fashion. For example OWASP ESAPI’s addCSRFToken() method. (see code)
2. ‘design review’ becomes a checklist activity in which security folk (playing the role of auditor) walk through a list of features they expected to include, such as those API calls described in #1 or at a higher level the inclusion of a particular security package: IE: “You’ve used ClearTrust for authentication–right?”

With regards to the software, infrastructure, and COTS these organizations purchase, they tend to apply a modified checklist (such as #2) during acquisition, and then–in the case in which they’re acquiring a security component itself–add it to the checklist for future reviews.

There are benefits to this level of framework creation/use (namely, it raises awareness of the problem, standardizes solutions making compliance easier to gauge, and does in fact place some useful functionality in the hands of developers they might have otherwise omitted or bumbled themselves).

However, I think this approach misses the mark for several important reasons.

Others build their security frameworks from scratch. Convinced that their organization is different enough to warrant their own unique approach they set to construction. Some organizations cull framework material from ‘centers of excellence’ within their organization: development teams that have already done a great job at something like demanding authentication and invalidating sessions. Others architect the security framework centrally, construct it, and then deploy it mandating development teams integrate with it as they continue otherwise normal maintenance of their apps.

There’s intrinsic benefit and difficulty to a purely bottom-up or top-down approach. If an organization goes purely bottom-up, their difficulty lies in coordinating and architecturally cohering different teams’ widgets into a common framework. The strength they can rely on is buy-in: developers are hard-pressed to complain about what they and their peers have written. The top-down approach lacks buy-in and (at times) practicality, but often enjoys a coherent unified design.

Early in ‘07, I wrote on a model for mixing the two approaches successfully.

Whether executed top-down, bottom-up, or through some compromise, I like this approach better than the one I described above. My biggest issues with it are:

1. It can become a political monster, especially if top-down
2. Being overly unique (ala: “not-invented here” or “I’m a snowflake” pathologies) can be damning

The more top-down an approach is, the more likely developers are to balk at mandates for the framework’s use. “Pfft, but that won’t work the way we built our app.”, they’ll lament. If you hear that, prepare for a deluge of exception forms. ;-)

So, how are people overcoming limitations of an ineffective feature-centric audit-model and the pains suffered from inventing their own framework from scratch? By, “meeting the developer on ‘their side of the river’”, as it was once said to me.

When a developer sits down to write or maintain a web application, they’re doing so within a very rich platform already. The .NET platform has well-integrated set of tools from the webserver up to application-support functionality provided by a single vendor: Microsoft. The Java EE platform focuses on open standards, and as such has a bevy of open-source packages that support the lower-levels of the stack that Sun provides. Simply put: a developer writing a Java EE web app is already conforming to the Servlet framework, if not the Struts, JSF, or some other MVC package. They know the platform’s packages, they’re already using them, and there are tons of great books, tutorials, and examples out there.
This is their side of the river. Demanding they build on top of those packages, but integrate with another package–for the sake of security alone–is folly.

A better answer to creating one’s own security framework–and I’ve seen this in play in more than one organization–is to secure a framework the developers already know. This:

• Maintains current platform design idiom - If Spring is ‘the right design paradigm’–great, you’re using with without having to have invented it;
• Allows consideration of the framework’s threat model - It’s easier to secure a system you know the design/deployment model of, than it is to write ‘the perfect’ security feature in a vacuum;
• Maintains transparency, as best as possible - Those securing the framework can place implementation ‘under the hood’ allowing developers to call functions as normal;
• Moves security ‘lower in the stack’
• Reduces integration points for developers

To me, these advantages are overwhelming. Showing the benefits of faithfully maintaining the underlying framework’s design could be the subject of its own entry entirely and–I feel–places the nail in the coffin of those arguing that security can be represented simply as features. I’ll defer that for now however.

Fixing problems instead of identifying them? Security guys getting traction by helping developers write code and get it out the door faster? Meeting them within the realm of the frameworks they’re already using: hardening their configuration, implementation, and deployment? This works?

Not surprising ;-)

Like Ken and Brian I’m pleased that results from this study are getting out there. I recently participated in the OWASP EU Summit, where Pravir and I conducted a session on the maturity model. The session had valuable industry participation.

One of the things I’ve harped on for years now is that experts need to pull their heads up from whatever they’ve gotten so good at doing in the weeds and avail themselves of some of the lessons learned by organizations that have been working on software security themselves. In 2006, I presented on “building one’s own software security group” and one of my first five slides uncovered a dirty little secret–true now as it was then: Fortune 500 security groups often possess more man-power and budget than security security consultancies. I see this maturity model study and the response/involvement of the people I’ve mentioned here as a giant step in the public recognition of the value security groups within large commercial entities have been providing.

To follow up on Gary’s InformIT article, I’ll be writing a series of posts on why these “Top 10 surprises” don’t come as a shock to us at Cigital and what it might mean for organizations. I’ll go in reverse order:

9. Not only are there are no magic software security metrics, bad metrics actually hurt.

First, a clarification. Gary’s article indicates that:

but even the most advanced programs don’t use any sort of balanced scorecard approach.

I certainly talk to organizations that rely on a scorecard, especially at the executive level, to report on software security activities. What’s interesting to me is the horror stories organizations tell about chasing the wrong metric. First, they lament how tracking “the wrong thing” motivated unexpected (and undesirable) behavior changes in the staff they were trying to effect. I’ve personally seen things like developers manipulating their code to break static analysis tools, signing a training sign-in sheet then leaving for the day, and vulnerability fixes that cause terrible residual risk (But pass a regression test in the form of a penetration testing exercise). Developers ‘hacking’ the system of control? We shouldn’t be surprised.

In my opinion, organizations charged the scorecard hill too early. They were frustrated with how “Fear-driven” security was but simply didn’t know what underlying measures would raise their visibility into key areas. Just as bad, they didn’t know how to take measurements precisely and inexpensively. I want to explicitly except organizations like GE from this analysis, BTW, as their rich history of scorecard management deserves its own treatment. For information on this, see GE’s presentation at Metricon 2.0.

Though there is often some pretty easy low-hanging fruit, leading organizations have begun to realize that deploying sensors to answer questions about software security spending is trickier than expected. Success involves looking at things on different levels than their budgetary line-items have defined. For instance, people are paying for penetration testing and they may have allotted money for a static analysis tool or code review services (or both). However, to determine and increase the efficiency of their assessment practices, organizations are finding more success with normalizing vulnerability findings reports, tying them back to what detected them, and generating “cost per findings” from there, rather than micro-optimizing each assessment technique itself. In my experience, this causes organizations to shift focus between assessment activities in ways that surprise them, but provide a profoundly cheaper overall assessment cost. As a result, organizations are surprised that a slight resurgence in penetration testing allows them to uncover authentication problems in their web applications more cheaply than the recently more favored static analysis tools are allowing them to. Likewise, simple customization of static analysis tools has allowed them to delete whole swaths of test cases that distracted or bloated their penetration testing efforts. More on this phenomenon can be found in my recent article.

I believe a scorecard will emerge. I believe metrics like “cost per finding” will begin to make sense and provide valuable decision support when organizations further mature the consistent application of their software security practices and realign the things they’re measuring. But, right now, great software security managers are conducting more “under the hood” diagnostics than “roll-up” reporting to increase effectiveness of their groups, reduce their cost, and weather this economic storm. No surprise there ;-)

Developers often ask security folk, “Hey, how do I protect credentials in config/property files?” or “Do I need to encrypt my production binaries?” I admire their asking security for help, but often times 1) they’ve not asked the question well enough to get a good answer and 2) security folk have a hard time getting to the root of the problem to provide decent guidance.

After teaching a threat modeling course recently I thought I’d demonstrate how considering an application’s architecture, who might attack it, and what impacts a business might face as a result of attacks interrupting or subverting the system’s ability to accomplish its business objective can be very helpful in framing context-free questions like I’ve posed above. I’m of course, talking about why threat modeling, even informally, is useful.

Let’s consider the above questions in a few contexts. I’ll ‘invent’ contexts for the purpose of this conversation, but you can likely see overlap in what you do with one or two, and incredible differences in the others.

Some circumstances will warrant protecting against threat actors making changes to configuration or the code loaded into the production environment in which extensibility of that environment’s code base and flexibility of its configuration are a reality. Examples of such environments might be:

• A mobile device or one distributed to consumers (such as phone, embedded device (TiVO, AppleTV, etc.) or similar)
• A outsourced hosting environment (Savvis, Google Cloud, etc.)

In both cases, you want to push updates or new applications/configuration in the production environment. Really, any organization that separates development from operations/deployment will have to ponder trust of its operators. Outsourcing is not a necessary condition.

“Insider” and “Administrator” threats apply in the second case, whereas a “Malicious User/operator” applies in the former. In all these circumstances, we need to rely on the actor to operate and in some cases maintain the system, but we don’t trust the threat actor with code and certain sensitive configuration elements. That’s a pickle.

In terms of the threats’ capabilities, we expect an Administrator to have intimate knowledge of (and ostensibly administrative control over) the host on which our application is deployed. They do not, probably, have reverse-engineering capabilities, or deft programming skill in non-script languages except in rare cases. Insiders may simply have access to the host (physically or through remote login), may possess the same role as the running application, but probably do not possess root privileges on our underlying host without successfully exploiting it. Their skill level will probably be less than that of an Administrator in most cases.

A malicious operator will run the complete gamut of skills as a matter of fact: there are plenty of deep technologists and tinkerers you want to sell TiVOs and cell phones to. Depending on the size of the market, the data or functionality to be protected, and the possibilities through which a “hack??? could be replicated and executed by non-skilled users (my mom will not not log into her TiVO but will definitely send her cell phone away to be “unlocked???), protective schemes may or may not be of much use.

It is because these threats’ vary widely in their skill set and their understanding of the construction of the application that I’ve combined consumer devices with hosting—seemingly unrelated architectures. Opaqueness and user/operator knowledge are slippery slopes. Some people hack their TiVO and some admins haven’t the foggiest of how to tickle an app

We’re drawn to potential impacts to make sense of the capabilities we discussed above and what they might be used for. I’ll treat each system architecture in term, giving a single attack scenario for each threat.

Hosting

The administrator lifts plain-text credentials out of a config file (u: oracle, pw: oracle) and conducts his/her own SQL-injection on the database, pulling tables and tables of user records, sells ‘em to organized crime: motivation, payoff, and impact. Let’s consider a code-replacement problem too, this time from the perspective of insider. An insider watches bug reports for a particular dev. team and after seeing a particularly insidious one, rolls back the version of production software to a vulnerable release, and follows the ‘script’ laid down by the bug report. He makes decent use of some coupon-codes, gets about 3-62??? flat-panels shipped to his house for $3, and runs.

Consumer Devices

Here, let’s consider two scenarios as well. First, the malicious operator—a consumer—twiddles with his/her DirectTV until I figure out how it stores/sends its username/password up-stream. Discerning a weak password scheme (computable from a username) and having heard a neighbor brag about his “NFL Sunday Ticket??? purchase, he/she downgrades service to the cheapest, then updates his/her DirectTV to send the neighbor’s username/password instead of their own. Beaucoup sports at petite pricing. In another scenario, imagine the malicious operator adding their own naughty code to the device to collect streams of content and drop ‘em to disk DRM-free.

One could imagine other goals, attack paths, and impacts easily. I’ve chosen these off the top of my head because they’ll demonstrate dramatically different protective schemes. I don’t know that they’re the most interest, common, or valuable scenarios to consider. I know-in some cases-that the scenarios I’ve listed are contrived.

Now, onto attacks and protective schemes:

Hosting: Code Update

Preventing insider (or even a malicious system administrator) from loading code can be accomplished by combining an organizational tweak with a platform feature (At least where Java and .NET are concerned). By demanding code and configuration (even code security policy) be signed before promotion into a production environment, and configuring the application container to check for these signatures, one can control what code executes in a particular container. Separating the “Application Deployer??? role (the one who signs and delivers code) from “Application Developer??? and “System Administrator??? prevents either from placing a rogue binary in place of the expected (signed) one.

Outstanding issues with this scheme include how to validate code to be signed. Did the developer inject back-door functionality that remains undetected? And, of course, how do you prevent an administrator from loading malware outside the application container (either side-by-side on the host or as a proxy between the application and a connecting system)?

Consumer Device: Code Update

Code signing has worked for consumer devices as well. Other encrypted binary format schemes have been employed to not only disallow unauthorized parties from loading code, but also for protecting the IP contained within code updates while in transport over Teh Intarweb.

An aside: I’ve seen a code signing scheme “to prevent malware from being placed on victims’ devices.??? However, they granted code signing certificates to anyone willing to register (with their address and some other information). Because they’d give signing ability to (basically) anyone who asked, their scheme did NOT prevent malware from getting onto the device. Instead, it only allowed for tracking of who was responsible for signing that malware ;-) Likewise, a system whose dynamic update function was protected by “proprietary encryption???, thus disallowing anyone from seeing patches or deploying malware in their stead. Because this “proprietary scheme??? was basically just LZW, it was trivially broken.

Consumer Device: Storing Credentials

Preventing a malicious operator from observing and gaming credentials will take an entirely different tack. Think about how smart cards or GSM cell phones work. In these cases (both potentially operated by unsavory folk), a card contains both logic and a secret, known to a central authority. When the central authority (a web site, something the smart card is docking with, or inserted in to) needs to authenticate the user device, it issues a challenge to the card. Logic on the card then computes a response to this challenge based on the secret it holds and issues a response. Even if the device’s user is able to intercept both challenge and response, it should remain opaque (and therefore not suffer replay).

Advanced techniques, such as Differential Power Analysis, may be able to extract key information from such schemes even when implemented correctly. A more interesting limitation of this scheme is plausibility of its deployment. Fobs are expensive to deploy and may not even fit within the architecture being analyzed.

Hosting: Storing Credentials

‘The trickiest of problems of the bunch to solve. I’ve seen a lot of different schemes discussed, some commercial, some home-rolled. One can thwart an administrator not skilled in reverse engineering and slow down a well-trained one by encrypting configuration, true. However, schemes that involve placing encryption secrets in the code that protect those config files can ultimately be reversed by a skilled administrator. Situations in which said secret was stored elsewhere and passed to the application to be used during start-up raise complexity a fair amount and can also be reversed if the administrator can debug or attach to the application’s process. And, to finish the summary, the credentials must ultimately be used somewhere. Often, it’s easier for administrators to MitM the application and that somewhere rather than do all this reversing we all find fun.

Once some kind of reasonable encryption scheme is employed (to prevent trivial attack), protective scheming should focus on detection of access to down-stream resources using lifted credentials, rather than making the problem THAT much more difficult to reverse. Think about it this way, the way I wrote up this threat, its attack scenario, and impact, it seems to me these efforts would be sufficient to exonerate the company from negligence in the case of actual attack. This may in fact be their goal, rather than preventing attack, as always depending on the impact of successful attack.

In turn, you can see that the way each problem was presented, its potential solutions vetted, and next steps were discussed depended on the threat and the architecture under consideration. I hope these few examples help frame and answer (or ask) your next “how do I secure” question.

Some people start “Security Testing” by buying and using a pen-test tool on project. Such tools uncover security vulnerabilities (though they seldom help with root cause analysis or even obtaining double-digit code coverage).

These tools are degenerate, at best, in facilitating a security testing strategy. Why? Because, these tools are “black box” tools. What are black box tools?

The term “black box” stems from old testing literature and means “without internal knowledge”. An external perspective has always excluded “code” but sometimes goes as far as (in my opinion appropriately) software design. Obviously, you need to know something about the application’s architecture and design to test it though and the slope gets slippery.

In the realm of penetration testing, the term “black box” often has meaning beyond the tester’s knowledge of the product. OSSTM defines “black box” to mean that neither attacker nor defender are given knowledge of each other. They mean for this test procedure to accurately represent the kinds of opportunities, need for stealth, accessibility, and exploit that a real attacker would have, and also to evaluate the defender’s abilities to identify and prevent or recover from attack.

Because black box tools to a large extent run canned tests they will not satisfy my security testing goal (see previous entry) of having run tests that one traces back to requirements. ‘Requirements that one created as a result of doing risk analysis that determines exactly what behaviors (and their impacts) should be avoided were the software attacked.

Arguably, security folk have “cached” this risk analysis and these implicit requirements in the pen testing tool. Fine, this is that small benefit that I mentioned pen tests do provide. And, they DO find bugs. Again, this is at best a degenerate case of security testing in the same way running a fuzz testing tool is a degenerate way of conducting functional testing.

For QA folk wary of accepting the previous statement, it will suffice to say that you wouldn’t defend your job based on achieving less than fifty percent coverage would you?

Vendors have begun using hybrid approaches (this will only become more common). Do these approaches solve our coverage problem and allay our concerns?

I demo’d Compuware’s DevPartner, which has a poorly advertised (and perhaps now nacent) security scanning capability, a few years back and was pretty impressed with the start they had made in hybrid .NET analysis. I’m not sure where it’s gone since then. Fortify’s PTA also combines static and dynamic analyses to help prioritize static findings and provide root cause analysis for dynamic ones.

These hybrid tools don’t get our security testers off the hook either though, as they’re still not addressing the project-specific risk analysis nor are they anchoring tests in requirements.

An organization can say they’re successfully conducting security testing when 1) they can trace test cases back to security requirements that embody the application’s ability to resist viable attack that would cause the business to suffer impact to its mission and 2) they enter security bugs in their bug-tracking software. They must then prioritize and fix security bugs like any other software change request.

Sounds like QA right? Well, it should. Rest assured, there will be techniques, tools, and knowledge required to make the above statement true that even great QA people, process, and tools won’t be able to accomplish without some help from Security. Can QA get to 80% on their own? I don’t think so. Can they make more than 20% progress? I think so. My intuition is that QA folk with good tooling and a small amount of training will be able to specify and implement about half of what I call both a good test suite and good security tests.

In my experience companies don’t do security testing. Some of the more advanced companies with respect to Software Security have it on their ‘08 and ‘09 roadmaps. Product companies are more likely to have integrated security testing practices because of their comparatively tester-centric culture and SDL (vs. IT shops).

What are you seeing out there?

Technorati Tags: software testing

Gunnar Peterson wrote an excellent post lamenting the lack of market forces in the security space.

I don’t know when we’ll see such market forces affecting companies but do agree they would have a positive impact. Certainly, I get why the security space hasn’t been subject to market forces yet though:

• People haven’t historically been ready to pay for it
• Companies haven’t entered the market with something valuable enough to invest in

First: what people are willing to pay for. Simple question: if a development team has a $10M budget, how much does it, say, spend on quality? 10-40%? OK. How much does it spend on software security?

Second: The security space, at least with respect to Software or Application Security, has indeed moved beyond its purely missionary roots: people know they face a problem. People do not, however, know what to do about it.

Lack of direction hasn’t resulted from the vendors’ failed productization of a tool set or services though. No, it’s resulted from the lack of mature solutions in the space. Penetration testing companies were gobbled up last year but my experience has been that, for the most part, customers haven’t been willing to invest in these tools far beyond their initial purchases and the smallest amount of shepherding.

In fact, most organizations I’m working with have seen either a reduction in reliance on or an outright backlash towards penetration testing. Use of static analysis tools and code review, while on the rise, has not reached ubiquity in response (We’ve yet to see what will happen in a broader context, having only completed what I consider to be the early-adopter phase).

What do we do about it? Partnering more closely with customers has been something I’ve felt very strongly about. Listening more closely to them remains crucial. Even involvement at this level can be tricky to fund at all but the most interested customers.

There’s work to do as vendors too. Because, while we’re through the missionary phase, we’re not through the education phase in security. We must spend more time helping clients understand what attainable next steps look like for them. Moreover, I think we have to work with them to solve some of the problems we’ve avoided: we need to clarify salient next steps ;-)

How are we really going to get enough security knowledge in the hands of developers to change their behavior in a sustainable way? How are we going to scale code analysis so that it has some of depth of expertise, manually applied, but all of the consistency and speed of automation?

Technorati Tags: software security

Last week, I gave a talk at QCON’s inaugural US conference, as part of Gunnar Peterson’s security track. There were some pretty serious speakers giving talks and I was thrilled to be amongst a set of developers with such deep quals.

I spoke about threat modeling because I think its a reasonable first-step towards implementing “Architectural Analysis”, one of McGraw’s most important touch points. Threat models aim to illuminate the intersection of technical risks (from technical vulnerabilities) and the business assets they target. An active SDLC work product, Security Architects (conducting secure design), Security Analysts (conducting code analysis), and test managers (planning destructive tests) should consume these models. They’re not shelfware.

Slides from my talk are available from the first link above, but I wanted to distill the key steps from threat modeling I covered therein:

1. Anchor the threat model on software architecture, that’s where the majority attacks against your application will occur
2. Identify assets (critical or sensitive data, and functionality) key to the application’s business function
3. Translate use case actors into threats, use into misuse/abuse. Start with normal use cases’ error conditions and alternative flows
4. Enumerate attack vectors each attacker may use against the application by pilfering the “low-hanging fruit” from community resources on vulnerability (such as the OWASP Top-10)

Tricks emerge along the way:

1. Show privilege escalation or increased system exposure (for instance from unauthorized Internet threats to authorized system use) through simple, common attacks. Show escalation to ‘insider’ in turn through similar attacks
2. Layer or combine simple attacks to penetrate systems more deeply
3. Show selective targeting of assets (victim clients, data stores, or application functionality) through particular attack selection

Finally, annotate threat diagrams by showing mitigating or compensating controls. While this wasn’t covered by my 50 minute session, its a critical part of a larger ‘loop’ of behavior that begins to create “design for security” out of “model threats”.

Enjoy.

Technorati Tags: threat modeling

I was talking with one of my consultants the other day about a common confusion Developers sometimes have regarding a pretty mundane piece of security guidance. Specifically, “What does it mean I have to turn off logging/debug in production?”

In my mind, these two separate issues exist here, intertwined.

Almost every logging framework has an in-place configuration option for increasing/decreasing log-level; most allow you to reconfigure on a running system without restart. The point here being that an application developer, with use of such a package, get to 1) keep a single code base, 2) turn a high level of logging off by default in a production environment, and 3) ratchet up log-level in circumstances requiring it (incident response or in-place debugging).

Often, people mix the above guidance with “don’t roll debug code out to production.” Code Analysis tools, for instance, give this advice. Two things principally concern me here. First, you don’t want a bunch of “main” or other “debug-only” entry points to the code. Attackers capable of compromising host systems could shoe-horn their way into an application this way. The situation becomes worse when said debug interfaces are web-based. Second, especially for thick clients or code running in less trusted environments, debug code tends to ‘express’ things about the design (or leak critical data) in an undisciplined manner. Removing such code from deployments to untrusted zones CAN be advisable, but one must balance complete removal with the need to ‘turn on’ nascent debug code in times of need as described by the previous paragraph. Only protection of the most sensitive information, and most invasive code qualifies for the extreme guidance “remove before deploying” that this paragraph describes.

The best thing one can do is give the developer guidance as to what types of test/debug code might qualify for wholesale removal. I’ll start you a list:

1. Client ‘harness’ code allowed to connect to server interfaces w/o
   authentication
2. Client code allowed to edit/manipulate local data repositories/stores
   directly
3. Command ‘harnesses’, allowed to (re)set or manipulate server state
4. Client code that dumps secret keys, tokens, or stored-but-otherwise-protected credentials
5. Backdoors
6. Code allowing for ‘insecure failure’ or back off, say to an older protocol
7. ‘Re-implementation’ outside a sandbox (native equivalents of a managed binary)

Just a small tidbit, away from the glib towards concrete guidance.

-jOHN

Technorati Tags: logging, debugging

In a recent article iPhone shell code hits the web HD Moore, creator of the Metasploit Framework describes how combining members of a set of implementation bugs in applications on Apple’s iPhone with a design flaw results in a ripe opportunity for landing shell code or otherwise controlling the phone’s various hardware goodies (camera, mic, speaker, etc.) remotely.

As you read the above article, note the classic vulnerability-types mentioned. The iPhone suffers from a design flaw: all apps running as root. Moore also mentions some of the simplest kinds of buffer problems (such as the stack-based buffer overflow).

These bugs, this flaw represent a low-level of organizational maturity in security. It almost seems a throw-back to any 90’s era code assessment I’d done. We’ve understood the stack-based buffer overflow well for years-upon-years and even rudimentary static analysis tools catch it. Threat modeling or simple architectural analysis should have dissuaded architects from moving forward design intact, bearing so fundamentally “risk amplifying” a flaw as “run as root”.

Make no mistake: Apple represents a company leveraging security by obscurity. I cringed when Apple used its then largely untarnished record as a marketing ploy, (from what I understand) without listening to what’s been said about the actual resistance of his products to attack.

While aspects of their desktop OS were truly “designed with security in mind??? and represent solidly secure OS technology, it’s clear to me that Apple does not address software security programmatically to what I consider an acceptable level.

When Apple created an asset of reasonable enough value and appeal, threats easily broke a shoddy system by retraining their attention on the protective mechanisms shielding that asset.

While a lot of our customers have adopted software security early, and have committed to addressing it in all phases of their software’s lifecycle, in all appropriate organizations touching software, others have not. If, reading this, you look at the well-covered transition from Microsoft to Apple as the vulnerability target and think by analog, “this stuff is happening to my competitor, but can’t happen to me”, or perhaps feel invulnerable because, “No one would figure these vulns. out.” or, “We’re not on people’s radar.” BEWARE. One ostrich is having to pull its head out of the sand and peck at crow… and this is sad because, with the exception of my Crackberry, I largely believe in and purchase from Apple.

A final thought: Regardless of the actual security in OS X, what chance does Apple have of touting Leopard’s security over Vista in the market place after these events?

Benjamin Tomhave wrote about “tiering” security guidance when I cross-posted a comment to my last blog entry on the SC-L mailing list. Quoting him:

The higher up you are in the policy framework, the more general and time-enduring the content should be. The farther you progress down the framework to a more detailed level, the more perishable the content will be, out of necessity.

Later he continues:

…is because implementers need it. They’re not security experts (usually) and do not necessarily grok security the same way a seasoned (salty?) security person might.because “implementers need it”.

This tiering was implicit to my first post. In fact your most senior security resources can probably use nothing but Security Principals (as described by McGraw’s BSS Book and the famous Saltzer paper) and find both insidious vulnerabilities as well as brand-new “Game over” architectural flaws with new development technologies they aren’t familiar with. But, the more junior (inexperienced) or development-oriented (constructive) the person being targeted, the more specific the guidance must be in order to be valuable without requiring inordinate effort.

Because we’re trying to change the behavior of the majority of our Developers–who range in skill from OK to Hero and whom may have never had even a security awareness class–I find “technology-specific” guidance moves the ball the furthest.

In my previous two posts I talk about forms various levels of standards take, and the way in which one might create it. It occurs to me that I all but showed the bigger picture and might as well follow up to do so. Below, you’ll find a map of how I show security guidance flowing throw and effecting a software development team (click-through for full detail):

As information moves from top to bottom and from left to right it becomes more specific and actionable, but also more perishable (as has been said). To build security in, one must think about security’s implications throughout the lifecycle, so I see no reason why security knowledge (regardless of how specific) shouldn’t mirror artifacts used to construct the application itself: software requirements, design, and the code itself.

Though not central to this discussion, the diagram has been annotated to indicate who should produce and consume this information. Here, I’ll point out that your centralized Application Security Resources can probably most effectively and efficiently create the generic security guidance, but will need help of Security Architects to create the more technology-specific guidance and garner broad buy-in.

My last post presented a brief model of how one might organize and fund this in practice.
-jOHN

Technorati Tags: knowledge architecture, software security