Correctly Assessing Security Risk

I found a security issue some time back, the logging of a long-lived security session token.  This token enabled me to access an internal client data service which only checked the validity of the token, not its right to perform the operation on the data I was accessing.  We had two types of tokens, managed by the same session token management service, one for clients (the type of token I had found in the logs), and one for trusted internal service accounts.  The client service did not care about the difference, and as a consequence I was able to access all client data with my token.

I raised a critical incident, but surprisingly, nobody raised an eyebrow, not even InfoSec.  In fact, I was asked why I (little old me) was raising a critical incident.  After all, was there a crisis?  The incident was closed immediately and I had to instead raise a work item against the relevant team, who only fixed it some weeks later - there were more pressing delivery deadlines to consider.

Then, a week later, I found that some system was logging client passwords when they were changed. This was clearly a critical incident, but I thought twice about raising it.  But I did, and boy did that stir the pond!  InfoSec were all over it, sending out a flurry of messages to senior management, and the issue was fixed that day.

Yet both incidents were critical.  Had I not used my trusty OWASP risk rating methodology spreadsheet to come up with an objective risk assessment for both?  You see, the ability to leak all our customer data is just bad as the ability to log in to a few accounts and cause mayhem.  We had strict money laundering controls, so financial theft was not the main threat, brand reputation damage was.

So what the hell was going on?

I think the issue is that of understanding security risk.  Most people can relate to a password breach, but the other breach was too technical for the average punter.  And there was the rub.

I think the answer to this is to establish rules like: if the risk rating is determined objectively to be critical, then it is critical, not: do I think it is critical?  Granted, some of the inputs into the OWASP risk rating model are subjective, but they are less technical, and thus harder to get completely wrong.

It has been suggested to me that the business needs to accept the risk, but are they really qualified to do so?  Surely it is InfoSec who, on behalf of the business it serves to protect, has to define and enforce SLAs for security risks?

Read More

Uniform Service Authentication and Authorisation

The problem with using short-lived access tokens to enable authentication and authorisation of service requests, is that they only really work for synchronous interactions which themselves are short-lived.  Access tokens in, potentially long-lived, asynchronous messages run the risk of expiring.

An interesting alternative is to use certificates to sign (and optionally encrypt) messages.  For example, service A sends a message via some number of queues to service B.  Service A has a private certificate which it uses to sign the message.  Service B receives the message, and uses the corresponding public certificate to validate the message signature, and since this would only work with Service A's public key, service B knows the message originated from service A, and can authorise the request accordingly.    This would work equally well for synchronous calls.

Of course, this means a lot of certificates deployed to a lot of places, but certificates could be obtained from a central service, and access control applied.

So service identity is sorted, but would about user identity?

I suggest that users and core services need to be separated by a gateway layer (application or service), which would be responsible for establishing user identity via some means (basic auth, OAuth, Kerberos, or whatever), and then sending a signed user identity assertion (along with any roles it might have) along with requests and messages, much like is done in SAML.  Downstream services would trust the gateway to appropriately establish this identity, and trust would be ensured by means of the above certificate mechanism.

If you're looking for an identity & access management system, then check out OpenAM.  ForgeRock are doing an excellent job of supporting it, and the major releases are open sourced and free to use. We use it at IG for SAML, OAuth, Windows SSO (Kerberos), LDAP authentication amongst other things.  It is very easy to configure, either manually or scripted (e.g. via Puppet), and provides us a resilient, scaleable, standard authentication capability.  It does also provide policy based access management, but we've not ventured there yet.

And there it is.

Read More

Evil Session Tokens

So we build a new web application, SIMPLES.COM.  Clients login, over HTTPS of course, and a session token is issued.  Since we don't want the client to have to log in frequently, we give the token a long lifetime, or at least a way of using it to get a new one.

The application will have to persist the token on the browser, so cookies are used.  We consider using browser local storage, but cookies seemed the best way to guarantee wide browser compatibility.

The application then validates every HTTP operation, using the session token in the cookie, and authorises access as appropriate.

Sorted.

Enter the hacker.

Client Joe Bloggs receives an email with a phishing link to dodgy website S1MPLES.COM (note the name is different), and clicks on it.  Joe is taken to a page where a few sneaky GET requests are sent to the real SIMPLES.COM website, and Joe's browser helpfully supplies the session cookie, since it's the correct domain, and the hacker now has access to Joe's data.

How do we fix this?

The first thing to do is not use cookies for authentication.  The web app must attach a session token header to each request.  That way the above Cross-site Request Forgery attack is not possible.

However, we now have a long-lived session token being passed around, but that's OK, because we use HTTPS.

Except we don't.  Not all the time.

SIMPLES.COM is accessible over HTTP.  Only the login page and secure site are via HTTPS.

So Joe, being a lover of coffee, and free WiFi, gets caught by a man-in-the-middle attack by Mr Evil with a portable WiFi router.  Mr Evil intercepts the requests, and the session session token sent with each request.

Mr Evil now has full access to Joe's account, for a long time.

The answer is to make SIMPLES.COM full HTTPS, and to use HSTS to ensure no opportunity for man-in-the-middle exists. And to add all the recommended security headers, e.g. content security policy.

Cool.  Mr Evil shrugs, and picks on someone else.

Much later, Mr Bored Developer is browsing through the application logs (helpfully made available via a log aggregator), when he notices that the session tokens are logged for all to see.

Not so cool.

So what do we do?

One way is to use an OAuth approach to issue not one session token, but two: a short-lived access token, and a long-lived refresh token.  The refresh token is stored in the application browser,  but is never used for access, only to request new access tokens.

Of course these access tokens could still be leaked, but being short-lived, should expire very quickly.

Much better.

P.S. Please, please don't build your own security solutions!  Spring Security and mature open source identity and access management systems such as OpenAM are a much better way to go.

Read More

Application Security Function

Application Security is the software development concern of proactively ensuring that the applications being built, and integrated with, are secure.  This will require that application security becomes a standard focus for all software development teams, along with delivery, architecture, and quality assurance.

I suggest that this needs to be achieved through:

Education

Everybody (including the business and delivery) needs to understand the importance of security.  At IG we had a very positive recent experience with a consultant who came into our offices, spent some time with our development teams, educating and instilling enthusiasm for the subject, and then closing with a company-wide demonstration of our application vulnerabilities at the time.  The presence of C-level executives at these demonstrations lead ultimately to the creation of an application security function (in addition to our already quite mature InfoSec function).

Standardisation

Adopt industry guidelines such as OWASP to ensure a consistent, best-practise approach to security.

Organisation

Security, like quality, does not happen by accident, and requires organized effort to achieve. Create a team of security champions, whether physical or virtual, to:

• collaborate on application security decisions
• raise awareness of application security best practice in development teams
• help teams understand application security threats via threat modeling
• help teams secure their applications via security test suites
• provide a developer communication and feedback loop on security matters
• collaborate closely with InfoSec, PMO and Operations to ensure appropriate goal alignment - resourcing security work will be a key challenge

Process

Integrate security with your software development lifecycle, specifically:

• create an effective security monitoring, incident, tracking and resolution process
• prioritise issues using the OWASP risk rating framework
• require teams to maintain security threat models for their applications
• create security cheat sheets and code review checklists
• create automatic security test suites

Testing

Testing is the only way to confidently assert that an application meets its requirements, and this is no different for application security. All applications should be required to have automated security test suites with adequate coverage. In addition, periodic, independent 3rd party penetration tests and architecture reviews should be performed.

The Challenge

Doing security is like taking out an insurance policy.  You don't have to do it, and might get away with it, but can you afford the consequences if you don't?

What do you have to lose?

Probably a lot.

Read More

Security-oriented Architecture

Split your monoliths into myriad services and suddenly your established security boundaries fizzle into non-existence.

I would assert that all services need to think about security, namely:

• authentication: who is calling me?
• authorisation: are they allowed to call me?  are they allowed to request this particular data?
• validation: is the message valid?
• confidentiality: is my sensitive data secure?  what is sensitive data?
• integrity: how do I know the request has not been tampered with?
• non-repudiation: how do I know the request came from a legitimate source

Yes, all services, even the internal ones.  Don't think of hackers as spotty teenage opportunists.  Think of  them as sophisticated criminal organisations that spend millions on stealing precious corporate data, or threatening brands with ransom attacks.  Loyal as I'm sure your staff are, are they immune to greed, revenge or blackmail?

That's not to say you might not answer the questions above differently for internal services, as opposed to edge-facing ones, but consider these issues you must.

Read More

Public Web Service API Management Solution

So, as part of your Service-oriented Architecture (SOA) strategy, you've decided to join the Web 2.0 rush to publicise your web service APIs and are wondering about how you might manage this.  Do you build something or are there 3rd party products to help?  The buy-vs-build decision is always a tough one, but you will need to consider your core business and competencies, as well as the product's support for the following:

Partner website - a public portal where consumers of your services will be able to register, obtain service keys, documentation, support, raise issues, join mailing lists, subscribe to RSS updates, download client libraries etc.

Key management - provision and management of API keys and ensure those are supplied with calls.  Support for OAUTH

Read More

Key considerations for securing your REST web service API

Securing your REST service API layer is not just about considering whether you should use OAuth 2.0 or not, or whether REST needs something like WS-Security.  It is about considering why you should care about security, who you are protecting your service against, what the risks are, and more general security principles than just authentication and authorisation.

Why?

Do your service API need securing?  The answer to this will depend on your business, and the nature of the service, but you will want to consider whether there are any reputational, financial or regulatory consequences to a security breach of your service, and if so, how to deal with it appropriately.

Read More

What is SOA - Service Characteristics - Composable

Composability is the ability of services to be used in orchestration scenarios by higher level services or processes. It is a special case of the reusability characteristic in that the services need to be uniform as well as reusable. The reason for this primary reason for this requirement is that the orchestrating service will in all probability but built using something like BPEL not a conventional programming language, so any variations in service style become more difficult to deal with.

Read More