ADVISOR DETAILS

RECENT BLOG POSTS

Enterprise API Management for Mobile Part 2 – Don’t Trust. And Verify

In the previous post we looked at some of the policy zones that an Enterprise API Management has in Mobile security, including: 1. External security policy: for the Mobile device -> API Management Layer message exchanges 2. Internal security policy: … Read more >

The post Enterprise API Management for Mobile Part 2 – Don’t Trust. And Verify appeared first on Application Security.

Read more >

Betwixt and Between – Service Gateway for Enterprise Mobile Applications

Over the next several posts, I will explore some of the core patterns for Service Gateways that provide access to Enterprise Mobile Applications that need to leverage enterprise apps and data. Before I go there – a word about risk. … Read more >

The post Betwixt and Between – Service Gateway for Enterprise Mobile Applications appeared first on Application Security.

Read more >

Complexity Management with Tokenization

Tokenization is a major trend in application and data security and Gateways are an ideal location to deploy tokenization services. Tokenization replaces sensitive data with benign data. The classic example here is PCI DSS, and the business value of tokenization is summed up here:

Thumb_Tokenization

Now I am no graphic designer, but let me take advantage of the Chinese saying that “1,001 words is worth more than a picture.” As much as I like the graphic above it does not tell the whole story. The 2/3 of the graphic starting from the left is “PCI Scope”, the 1/3 on the right is outside PCI scope. In my experience the value of tokenization and gateways is that its more like 10-20% of the system is isolated down to in scope for PCI and the remaining 80-90% is “out of PCI scope” – *this* is the value of tokenization – it abstracts away a ton of complexity. As we discussed in the last post, complexity is the main enemy for security people. Tokenization services are a good way to not eliminate but massively reduce the sprawl of sensitive data and in doing so reduces the burden of complexity across the system because the rest of the system isn’t dragged into scope.

The reality is that most of the system does not need to access sensitive data such as payment information, it only needs to be able to reference authorization codes and the like. There are so many ways to mess up code that simply removing the sensitive data in as many places as possible is frequently the single most effective security mechanism. To quote Ken Thompson, “when in doubt use brute force.” What’s simpler – A) exhaustive audits, quarterly vulnerability assessments, section 10 level audit logging, and the full compliance check box olympics across your whole systems or B) brute force – isolate sensitive data, audit that island and expose only tokens and authorization codes to the rest? Its not even close.

The counterargument to the above is that a gateway introduces a new layer in the system and so its another middleboxen for the app server to talk to, another system on the critical path. Fair enough, but its there for a reason same as the app server is in the middle tier. The appserver is in the middle tier so that business logic and rules are centralized and reused. This is the same rationale for tokenization on a gateway – centralize the token generation and verification. Do you want all your developers writing code for generating and verifying tokens? Not bloody likely.

Tokenization is a major trend in security because it allows systems to reduce the sprawl of sensitive data and the attendant vulnerability and audit issues. Gateways are the ideal way to deploy tokenization because

1) the internal core operations of token generation and verification are too important to be left to individual developers. They are generic enough that they can be reused.

2) the external interfaces to the tokenization servicess- generate token and verify a token – are very simple

This is a mix that solves important security problem in a simple way and in a way that scales. Frankly there are not too many times in security architecture where this is the case and that makes tokenization on gateways is a design pattern for the long haul.

The post Complexity Management with Tokenization appeared first on Application Security.

Read more >

Remember Your Helmet

“I have three mailboxes in my office : IN, OUT, and TOO HARD. I was joking with the MIT students that I should have a TOO HARD bin” – Warren Buffett

Even for a great investor like Warren Buffett, most investing ideas wind up in the TOO HARD bin. Investing is a great in that way, where you can pick and choose which problems to tackle. There is no penalty for sitting it out when things are too complicated.

Unfortunately, in security we do not have this luxury. Our dev teams need to ship. Preferably sooner rather than later. Oh, and attackers will be looking for holes from minute one.

Like Warren Buffett’s mailboxes, virtually EVERYTHING that comes into an Information Security team’s inbox is TOO HARD. But unlike investing, we cannot really sit it out and wait for all the planets to align, we have to act.

There is a lot of evidence that information security is TOO HARD. Over the years, there have been plenty of examples of breaches where the victim companies did not do the basics – they did not have a firewall, they did not hash/salt passwords and so on. But nowawdays the victim companies are increasingly doing many things right and still getting hit. Its not a mystery, the design, deployment and operational challenges are hard. What to do?

This brings me to another of my favorite Buffett quotes- “The sign above the players’ entrance to the field at Notre Dame reads ‘Play Like a Champion Today.’ I sometimes joke that the sign at Nebraska reads ‘Remember Your Helmet.’ Charlie and I are ‘Remember Your Helmet’ kind of guys. We like to keep it simple.”

Security is too important to be left to development teams. But integrating security is too hard to be done by the security team alone. We talk constantly about threats and vulnerabilities and 0 day and SQL Injection, but our real problem is complexity management. There are ways to improve our security, but we have to choose wisely and make the things we choose simple enough to deploy.

Keeping it simple starts with ensuring the system has the right structural security pieces in place. For many apps today like Mobile apps this means adding an API security layer. Before getting wound up about the latest and greatest threats, remember your helmet, ensure that your DMZ, Middleware and Data tiers have protection in place, not just at the network layer but at the Application and message data layer too. Its often the case that too much focus on latest and greatest security topics obscures more fundamental issues.

In the Security Gateway Buyer’s Guide, I explored some of the important capabilities that security gateways offer. It’s up to security architects to identify the right mix of security controls and then simplify the model to something that fits in the operational architecture.  Getting the right structural components in place is important because it sets you to deal with a wide range of challenges.

We know security architecture is TOO HARD. We know that whatever we do today won’t be good enough next year, threats are too adaptable and most sotware assets that we protect are not particularly resilient. We cannot predict what the next threats will be, we cannot predict what will be the right identity standard in 2016 (OAuth? SAML? Something some kid at Caltech is cooking up right now?).  But we can say with confidence, we’ll need a place to patch and defend against threats. We’ll need a place to deploy new identity protocols.

Engineering is about embracing constraints. For technical complexity and economic reasons, we simply cannot defend everywhere in the whole system. We have to choose where to locate our stronger defenses.

Boundary crossings are crucial to security, you leave one trust zone and enter a new one. The API layer is a very important boundary, it’s the logical place to drive security controls that can effectively handle application, identity and message data threats and countermeasures. When you are deploying Web, Cloud, and Mobile apps, remember this boundary. Remember your API Security.

The post Remember Your Helmet appeared first on Application Security.

Read more >

What Comprises a Mobile DMZ?

The DMZ is a Web app security architecture workhorse. The DMZ operates under a different ruleset both in terms of what is allowed and in terms of the level scrutiny design, deployment and operations get. To the extent Web security works at all, its due in no small part to the isolation the DMZ provides.

The DMZ concept has lived on in the Web services world primarily through Web services gateways which limit Web Services attack surface, help developers navigate byzantine security protocols, and facilitates inbound and outbound app monitoring.

Here we are in the first or second inning of Mobile apps, will the DMZ still play a role? I think the answer is a resounding yes. The DMZ will continue to serve an important role but the nature of the role and the capabilities will adapt for Mobile apps. I think the DMZ still plays a role and is supported by the Web Service Gateway, but in addition expect to see increased deployments of API Security & Management layers to handle some front facing tasks

 

Capability

What Stays the Same

What Adapts
Identity &

Access Mgmt

  • Authenticaiton
  • Authorization
  • Audit
  • Support for OAuth, OpenID Connect
  • Key mgmt (developer, user)
  • Mobile Session management
Defensive

services

  • Limit Attack Surface
  • Malicious content
  • Monitoring access
  • Support client encryption
  • Lost, Stolen Use case support
Enablement
  • Publish apps and content
  • Centralized Policy enforcement
  • API Curation
  • Facilitate new roles

For Mobile Secuirty architetcure I expect each layer in the DMZ to handle similar responsbilities as they have to this point but to take on additional responsibilties with a mobile flavor.

Identity is the new perimeter, and so Identity and Access Management is a core problem at the DMZ. There is a clear need to support different token types and different protocols for mobile apps. OAuth and OpenID Connect are two of the most important here, but importantly its not just session cookies, the type ot identity token and protocol will change and so will how they are used. The session length is longer and there are local client based access control decisions to be made. The Mobile DMZ must have a way to enforce security policy for apps and data over asynchronous protocols.

In addition the access control protocol is often not just a client –> server, the security architect must account for the app developer who gets access via an API. The Mobile DMZ must have a way to issue, validate and refresh developer keys.

The Mobile DMZ serves an important function in providing defensive service, limiting what the app has access to and monitoring that access.Two additonal responsbilities include dealing with Lost/Stolen aka Remote Wipe. Many enterprises look to MDM here and that plays a role but does not help much on consumer facing applications. Client side data is often encrypted and here the Mobile DMZ is very likely involved to provision keys.

The DMZ is really about managing enterprise risk – publishing some data and functionality, while limiting the downside. This delicate balance is a result of the tension of push by development organzations and security’s job to ensure prudent measures are taken to manage the risks. API Curation is an important step ring fencing the scope of the enterprise mobile interface.

To support these activities new organizational roles must be fostered including the Service Admin and API Developer role. The Service admin readies the backend enterprise services to be published. The API Developer builds content on top of them. In addition security architects and app developers must factor in how to collaborate with these folks to ensure a clear chain of responsibility – who does what. For example, the Service Admin can instrument policies for security, measurement and monitoring, but the API developer is responsible to develop the front end. Understanding what is published and how to safely use the services is key.

So I think the DMZ is here to stay, I expect the some changes, some structural, some subtle. The structural change is the decoupling of the front facing part of the DMZ to API Security and management systems with the back end enterprise gateway served up by Service Gateways. Its still early days in mobile in general and mobile secuirty in particular but I think this shift already under way.

The post What Comprises a Mobile DMZ? appeared first on Application Security.

Read more >