OWASP - Michael Coates

The software security field sometimes feels a bit negative.

The focus is on things that went wrong and people are constantly told what not to do.

Build Security In

One often heard piece of advice is that one cannot bolt security on as an afterthought, that it has to be built in.

But how do we do that? I’ve written earlier about two approaches: Cigital’s TouchPoints and Microsoft’s Security Development Lifecycle (SDL).

The Touchpoints are good, but rather high-level and not so actionable for developers starting out with security. The SDL is also good, but rather heavyweight and difficult to adopt for smaller organizations.

The Software Assurance Maturity Model (SAMM)

We need a framework that we can ease into in an iterative manner. It should also provide concrete guidance for developers that don’t necessarily have a lot of background in the security field.

Enter OWASP‘s SAMM:

The Software Assurance Maturity Model (SAMM) is an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization.

SAMM assumes four business functions in developing software and assigns three security practices to each of those:

For each practice, three maturity levels are defined, in addition to an implicit Level 0 where the practice isn’t performed at all. Each level has an objective and several activities to meet the objective.

To get a baseline of the current security status, you perform an assessment, which consists of answering questions about each of the practices. The result of an assessment is a scorecard. Comparing scorecards over time gives insight into evolving security capabilities.

With these building blocks in place, you can build a roadmap for improving your capabilities.

A roadmap consists of phases in which certain practices are improved so that they reach a higher level. SAMM even provides roadmap templates for specific types of organizations to get you started quickly.

What Do You Think?

Do you think the SAMM is actionable? Would it help your organization build out a roadmap for improving its security capabilities? Please leave a comment.

Filed under: Application Security, Information Security, Software Development Tagged: maturity, OWASP, SAMM, SDL, security, Touchpoints

Today I want to take a little detour from the Robust Application Security track, and focus on a common problem that many application security professionals struggle to manage every day - what to do when speed to market and functionality trump the addition of security into a product.

As an aside, the idea for this post comes from an excellent post by Peter Gillard-Moss entitled Weighing the Cost of Expediency.

The Problem

As almost every security professional knows, there WILL come a time where you are consulting on a project, and either the project team or "the business" will choose to forego adding some bit of security into the project for the sake of getting to market faster, adding some last-minute must-have feature, or saving project cost. We will assume here that they are not being intentionally negligent, as that is really another case entirely. Similar to the situation Peter presents in his post, the team assures you that they will add that bit of security in during the next release cycle, or the first round of bug fixes which is tentatively scheduled for next month, and by the way your company is not a huge target for hackers anyway, so what's the harm. Assuming you agree with the proposal, everything continues on and now it is time for the security to be added. It's not on the agenda though! Here is where you, the project management, and the development team went wrong.

The Issues

The simple fact is that both you, the project manager, and the development team all screwed up. The reason that this happened is because, just like in Peter's scenario, your reasoning was flawed. You all chose the quick win thinking that all things would be equal down the road. The problem is, nothing is EVER equal down the road. Things change, especially priorities.

Issue #1 - Adding security in will be a priority (later)

The Solution

There is no shortcut to security. It should be just as much a part of a system's initial requirements as the functional specifications given by the business. To be effective at our jobs we have to get out of this operational, IT mindset and start to think in terms of the way our companies do business, and was that we can influence that. This is the way that you get ahead of the curve and start winning. This is where you really start to make a difference, and become a partner to the business. We are all "the business." We work FOR our companies just like the analysts and project managers do. To make a difference we have to start contributing to what they see as important. We are not here to say "No" all the time. Instead, we are here to say "Yes, we can do that as long as we take care to safeguard against these risks." Trust me, when phrased the right way in language that they can understand, these people can be some of your best friends. When you build that trust, they can also be some of your biggest supporters.

Break out of IT. Stop being "the security guy/gal." Be the person who provides solutions to the risks that the company NEEDS to take in order to stay competitive. When you can do that, then you will know you have succeeded. Some stuff to think about.

Until next time, happy hacking!

@matt_presson

If you are a vendor considering to start a similar initiative, please read it carefully.

The Five Golden Rules:

1. Build trust, with facts

2. Fast turn around

3. Get security experts

4. Adequate rewards

5. Non-eligible bugs

Happy Bug Hunting, Happy Bug Squashing!

Ensuring that attackers don’t forge requests in your web applications can be a tricky businesses, one that often requires a hand-rolled solution.

As soon as you have a session, you need to start thinking about cross site request forgery (CSRF). Every request to your site will contain authentication cookies, and HTML forms don’t abide by the same origin policy (SOP).

One method of ensuring that destructive requests (PUTs/POSTs/DELETEs) to your site are made from your domain, is by only allowing requests with a Content-Type header of application/json. The only way to set this header is via Ajax, and Ajax requests are limited to the same domain.

However, there have been active vectors in the past that have allowed header injection (such as some of the Flash exploits), and Egor, who is the expert in these things, assures me it’s not enough.

The classic method of preventing CSRF attacks is via a token that you pass with every destructive request. The idea is that attackers can’t get hold of this token (because of the SOP), and thus can’t forge requests.

If you’re using Rails, you get this for free. If you’re using Rack, than Rack CSRF is your best bet. It’ll deal with generating tokens and checking requests. The only part you have to handle is on the client side.

jQuery has a neat feature called ajaxPrefilter, which lets you provide a callback to be invoked every Ajax request. You can pass a CSRF token to the client side via, say, a meta tag. Then set a header using ajaxPrefilter.

var CSRF_HEADER = 'X-CSRF-Token';

var setCSRFToken = function(securityToken) {
  jQuery.ajaxPrefilter(function(options, _, xhr) {
    if ( !xhr.crossDomain ) 
        xhr.setRequestHeader(CSRF_HEADER, securityToken);
  });
};

setCSRFToken($('meta[name="csrf-token"]').attr('content'));

In the example above we’re retrieving our CSRF token from a meta tag in the page. Then we’re ensuring that any local Ajax requests forward the token as part of the request’s header.

Earlier this year I wrote about 5 ways to implement HTTPS in an insufficient manner (and leak sensitive data). The entire premise of the post was that following a customer raising concerns about their SSL implementation, Top CashBack went on to assert that everything that needed to be protected, was. Except it wasn’t, at least not sufficiently and that’s the rub with SSL; it’s not about having it or not having it, it’s about understanding the nuances of transport layer protection and getting all the nuts and bolts of it right.

Every now and then I write posts like that and every now and then the company involved doesn't do very much about it at all (hi Tesco!) But this case is a little bit different, this time Top CashBack deserves some credit not only for fixing their issues, but for objectively reaching out to discuss the findings and making some very pragmatic, balanced decisions about which pieces of HTTPS to implement and importantly, which ones not to.

The purpose of this post is to show how simple many of these fixes can be and to also point out some of the real challenges that organisations face when rolling out HTTPS on a broader basis. They’re both interesting stories and are a worthwhile addendum to the original post.

Solution 1: Sensitive data always goes over HTTPS

This is a bit of a biggie because it’s really HTTPS 101; you send anything sensitive over the wire, it gets transport layer protection. End of story, no more negotiations. Here’s what used to happen:

Not only was the password field loaded over HTTP (which of course we know means that it may be manipulated by an attacker to do nasty things even if it posts to HTTPS), it also posted to HTTP. Now it does this:

But wait – where’s the HTTPS? Well at this point you’re not entrusting the site with anything of a sensitive nature so for the moment, there’s nothing to protect (and that includes forms that you might then entrust with sensitive data). Anyway, try to join and you’re now taken here:

Now we’re seeing HTTPS and of course now I’m also prompted for sensitive data in the form of a password. There’s now the opportunity to see the HTTPS scheme in the address bar and if desired, inspect the certificate before entrusting the site with your credentials.

Why not load the first page over HTTPS? I’ll come back to that, let’s tick off the other boxes first.

Solution 2: HTTP content doesn’t go into HTTPS pages

Browsers get rather unhappy about this and rightly so; once you whack data from an insecure connection into a page loaded over a secure connection then you can no longer have confidence in the overall integrity of the page. I show you how to do rather nasty things with this in my video on mixed content warnings.

Previously, verifying an email account resulted in this:

That’s a rather unhappy little browser warning down the bottom. Now, however, the page looks like, well, pretty much the one above but without the warning. You see it only takes one little absolute reference to an insecure scheme, say to embed a JavaScript file, and you get hit with mixed content warnings. That’s easily fixed by using either domain relative paths such as “../scripts/foo.js” or protocol relative paths such as “//topcashback.co.uk/scripts/foo.js”. They’ve opted for the former and the warning is gone. Job done.

Solution 3: No more auth cookies over HTTP

The auth cookie is that little piece of stateful data that gets sent in the request header across the stateless protocol that is HTTP. It’s what keeps us authenticated across requests and it’s also what an attacker uses to hijack a session. Send it over an insecure connection and you’ve got serious issues.

After logging in and navigating back to the homepage served over HTTP, here’s what we used to see:

See the “My account” info in the top right of the page? The site knew you were still logged in because the auth cookie was sent with the unencrypted request. Whoops. Here’s what it looks like now:

Wait – what?! It’s still the same – an HTTP request and there’s a link to the account. Well it is and it isn’t the same and the difference is very important. To explain exactly what’s going on, let’s move onto the fourth point.

Solution 4. Auth cookies get marked as secure

The idea of cookies is that they persist state across requests. I know I’ve already said that but it’s important. The other thing that’s important is that you can have multiple cookies for one site. Yes, yes, I know that you probably know that too but here’s the important bit: the security profile of those cookies doesn’t need to be the same and there are cases where it’s perfectly legitimate to send a cookie across an insecure connection, it just can’t contain anything of value to an attacker.

It makes more sense when you look at the cookies for the site in Chrome’s developer tools (it frankly does a much better job at this than IE’s):

What you’re seeing right up the top is two auth cookies – one is secure, one is not. When the .TCB-BAS cookie is present you’ll get nice “My account” and “Log out” links so you get a sense of persistence. In fact you can even hijack this cookie as an attacker would and then follow the “My account” link but – but – before seeing anything of a personal nature, you’ll see this:

What this means is that there’s a two-tiered auth cookie approach. The secure cookie – that’s .TCB-AUTH-1 – must be present in order to view account info. This means that you have the best of both worlds in the sense that one cookie allows the user to still be identified on insecure pages whilst the other cookie will only work over HTTPS and that’s the one that does the sensitive work. Oh, and just to clarify a point at the end of my earlier post, whilst a bunch of personal data can be pulled out from the account section, apparently banking data is obfuscated which is good news on the security front.

But why not just serve everything over HTTPS? I know, I know, I’m getting to that, one more thing first.

Solution 5. Not relying on HTTP to load login forms

The last major HTTPS issue they had was that when clicking the “Login” button on an insecure page, you got this:

Don’t be fooled by the padlock image! The login form is actually a secure page loaded into an iframe, only thing is that you don’t know that and because it’s embedded in an HTTP page then a man in the middle could have actually loaded their own login form instead. In fact here’s a video of exactly how that works.

Now hitting the login button from anywhere gives you this:

This is a fundamentally different security profile as you can observe the HTTPS scheme, inspect the certificate and establish the authenticity of the page before entering your credentials. Oh – and the only padlock in sight is the one presented by the browser as a means of independent verification that the connection is indeed secure.

In some ways this is a usability concession as it requires an entirely new page to be loaded before the user can login rather than just populating a little iframe. Of course this pattern could still be used if the parent page was served over HTTPS, so why isn’t it? Why not just make everything HTTPS? Ok, let’s tackle that:

Why not HTTPS everywhere?

Ultimately, we’re going to see a lot more HTTPS everywhere and by everywhere I mean each and every resource being served over a secure connection; the page itself, the JavaScript, the CSS, the images – you name it – it will increasingly only be available over a secure scheme. But we’re in a transitional phase as an industry and as of now there are some hurdles to overcome.

One of the best analyses I’ve seen of the challenges HTTPS everywhere poses is from Nick Craver of Stack Overflow where earlier this year he wrote about Stackoverflow.com: the road to SSL. Nick makes many important points in his post including:

1. Their ad network (Adzerk) needs to support SSL
2. Their image hosting service (i.stack.imgur.com) needs to support SSL
3. Images embedded from other services need to be loaded over SSL
4. There’s a cost impact from CDNs
5. There are considerations around the impact on web sockets
6. Load balancers need to terminate the SSL connection before hitting the web farm
7. Multiple domains add challenges to the cert validity
8. They simply don’t know the impact on SEO – and that’s a critical one

Stack Overflow, of course, is a significantly larger proposition than Top CashBack but they have a number of similar issues they’re facing. For example, the SEO issue – how will search engines behave if they end up HTTP 301’ing (assuming a permanent redirect) to every resource they’ve already indexed? And the biggie (which is arguably the showstopper) is that Google doesn’t support SSL on the Adsense network (at least not at the time of writing) so there’s an entire revenue stream out the window. It’s hard to argue with that.

Security needs to be tackled with a healthy dose of pragmatism and frankly that’s often missing in these discussions. At the end of the day, security is but one of many considerations in the melting pot that is running an online business and ultimately it has to support the objectives of that business. Of course one of the objectives is to not get pwned and that’s where a discussion of risk versus impact versus cost comes into play. This probably wasn’t originally done at Top CashBack with full cognisance of the “risk” component, but it’s reassuring to now see this understood and IMHO a healthier balance struck between those objectives. Even still, as you’ll read in some of the comments on their blog post, change is not without impact so credit is due when an effort is made to improve things.

Looking to the future, if I was to be involved in a new project today where there was a need to use any SSL whatsoever then I’d be very inclined to just secure the whole shebang over HTTPS. There’d be no worry about SEO, you can could be selective with 3rd party content providers and there’d be no retrofit effort. The old concern of adverse performance impact on the client or server has been pretty comprehensively disproven (at least any tangible impact has) as have concerns about caching. SSL has matured. Browsers have matured. It might just be time for HTTPS everywhere.

Disclosure

Top CashBack responded well to my original post – their focus was on improving their security position and they were open and receptive to feedback. We spoke on the phone, we emailed we had a couple of points of differing views but it was always informed and constructive. There was no financial engagement sought or offered nor any oversight on this post, they simply got on with the job of securing their environment. Kudos to them.

A one-sized fits all approach to Software Development Life Cycle (SDLC) security doesn’t work. Practitioners often find that development teams all have different processes – many seem they are special snowflakes, rejecting a single SDLC security program. This may not be much comfort to somebody who needs to lead a SDLC Security initiative across a large organization – but in our experience it is possible to build a program of application security that works for different development teams by recognizing that each SDLC tends to fall into one of three patterns: Waterfall, Agile and Continuous Development/No Process. Your secure SDLC initiative should provide a toolkit that works for each without severely impacting the developers’ productivity. Our whitepaper presents detailed guidance on how to embed security requirements into each.

Characteristics of the Three Patterns for SDLC Security:

1. Waterfall: Development with big upfront design.

• Managed by a central person or team of Project Managers (PMs).
• May be iterative, but generally has long release cycles (i.e. quarterly, bi-annual or annual releases).
• Common in highly regulated industries, large enterprises, and software vendors who create expensive to patch software (e.g. shipped software, embedded devices).

2. Agile: Iterative development

• No formal project management as compared to waterfall. Scrum masters are responsible for watching over process while product owners are responsible for setting priorities.
• Each release results in shippable software – typically 1-4 week releases.
• This tends to be the most popular style for internal applications, mobile applications, and increasingly external-facing web-based applications. In general, we see agile as the most common pattern of development for new software.

3. Continuous development/no process: Either hyper-optimized with automation, leveraging continuous integration tools like Jenkins configuration management systems OR absolutely no development process or standardized tooling, such as Application Lifecycle Management (ALM) tools. Both styles impact security requirements as such:

• Releases and even iterations are completely removed from the picture – software is in a continuous state of release, with no chance to embed security ahead of time.
• Absolute minimization of process overhead.
• Cost of a defect is low, since it’s relatively easy to deploy a fix.
• Continuous development is very popular with eCommerce companies and other Internet-based businesses.

Each style tends to have different needs from a secure SDLC standpoint:

 1. Waterfall

• Willingness to spend-time up-front to “do it right” – if and only if the business thinks security is a priority.
• With sufficient buy in, design-time analysis such as threat modeling, and longer cycles on security activities such as a full-scale code review are conducted.
• Can accommodate several different security assessment techniques.
• Cost of fixing a security vulnerability can be extreme, the window of risk exposure can be particularly long if it involves end users patching their systems

2. Agile:

• Primarily feature driven, particularly when adopting user stories as the primary method for conveying requirements.
• Typically do not have any process around managing non-functional requirements
• Can adopt security into iteration planning process by baking security requirements into product backlog.
• Emphasis on automated testing, whenever possible – may be able to accommodate manual testing from QA or security teams.
• Cost of fixing security vulnerabilities/window of risk is lower than waterfall, but there is still an emphasis of shipping defect-free software.

3. Continuous development / no process:

• Obsessed with automation and protecting developers from process overhead. Anything that requires developers to take time away from coding is often met with fierce resistance.
• No ability to plan up-front except on a per-feature or per-change basis.
• Often willing to invest in building security features into frameworks, automated front-end tools to shield them from developers.

Recognizing the three patterns and providing toolkits that work for each can dramatically lower the resistance for a SDLC security initiative. Read our guide on how to embed requirements into each.

Also see:

• 3 Reasons Why a One-size Fits all Secure SDLC Solution Won’t Work
• Take 15 minutes to uncover your high risk vulnerabilities
• Why you shouldn’t use the OWASP Top 10 as a list of software security requirements

 

 

Findings from August survey is 86 percent of business owners feel that current website is secure

The lack of incentives for security effectiveness remains a problem for security professionals. Until we define legitimate success criteria as the basis to align the organization around security, nothing will change

Note to self ... add attachment 'secret-algorithms.zip' ...

Three men have been charged with pilfering trade secrets from a Wall Street firm after two of them emailed themselves computer code belonging to their former employer from their company email accounts.…

Posted by InfoSec News on Aug 27

http://www.nextgov.com/cybersecurity/2013/08/contractors-now-using-encrypted-calls-and-text-legal-advice/69341/

By Aliya Sternstein
Nextgov
August 26, 2013

With economic espionage and domestic surveillance creating a climate of
cyber insecurity, some intellectual property attorneys now employ
encrypted communications to correspond with federal contractor clients.

Tools such as RedPhone, a mobile voice app, and Silent Circle, a text,
video...

Just because it's simple to use doesn't mean the user is low-rent

The Poison Ivy Remote Access Tool (RAT) - often considered a tool for novice "script kiddies" - has become a ubiquitous feature of cyber-espionage campaigns, according to experts.…

Posted by InfoSec News on Aug 26

http://www.autoblog.com/2013/08/25/tesla-model-s-vulnerable-hackers/

By Damon Lowney
AutoBlog
Aug 25th 2013

Next time you walk by a parked Tesla and its sunroof is opening and
closing with nobody sitting inside or around it, you could be witnessing a
hacker moment. For all of its strengths as a car, the Model S reportedly
has a weak spot: the security of its API (application programming
interface) authentication, according to an article in...

All your account are belong to us

PayPal has fixed a critical flaw that allowed an attacker to delete any account at will and replace it with one of their own.…

As the software giant works to fix the shortcomings in its latest set of patches, security experts debate whether "trust the patch" is still the best course

Read 10 remaining paragraphs | Comments

Read 12 remaining paragraphs | Comments

Read 10 remaining paragraphs | Comments

Security bod predicts future where virus writers steal your lunch

Antivirus guru AVG is preparing for a future where even fridges and freezers are targeted by malware, the firm's chief operating officer has said.…

So warns the Internet Watch Foundation

Innocent companies' websites are being hacked to serve images of child sex abuse, the Internet Watch Foundation has warned.…

Researchers who hacked Toyota Prius and Ford Escape hope to foster future 'car-in-a-box' model for tinkering with vehicle security issues

Read 1 remaining paragraphs | Comments

Read 3 remaining paragraphs | Comments

Read 8 remaining paragraphs | Comments

Send for the doctor, send your IMEI to attackers

Virus-hunter Symantec says the Android master key vulnerability is being exploited in China, where half-a-dozen apps have showed up with malicious content hiding behind a supposedly-safe crypto key.…

Just in case anyone wanted to add CEO of Yahoo! to your online CV

Facebook-for-bosses website LinkedIn has fixed a security vulnerability that potentially allowed anyone to swipe users' OAuth login tokens.…

Hundreds of millions stolen from biggest names in US

Federal prosecutors in New Jersey say they've busted what could be the biggest credit card hacking fraud in US history, with companies such as NASDAQ, 7-Eleven, and Dow Jones falling prey to an Eastern European criminal gang.…

'Hacker 1' and 'Hacker 2' from the Heartland Payment Systems breach indictment were named today among the five defendants in latest breach charges that resulted in 160 million stolen credit card numbers and hundreds of millions of dollars in losses

Major holes in network video recorders (NVRs) could result in a major physical security and privacy FAIL

Brooding silence bugs code-cutters

After days of silence over an outage that's outraged developers, Apple has announced that its Developer Centre was subject to an attempted intrusion.…

Posted by InfoSec News on Jul 22

http://articles.timesofindia.indiatimes.com/2013-07-20/india/40694913_1_cyber-attacks-ntro-guidelines

By Rakhi Chakrabarty
The Times of India
July 20, 2013

NEW DELHI: Cyber attacks on ministries, including home, external affairs,
power and telecom, could soon constitute cyber-terrorism and could be
punished with life imprisonment. Tough new guidelines were released by
national security advisor Shivshankar Menon on Friday by which these...