by Shawn McKinney

Year of the Hack

2014 will be remembered as the Year of the hack.

Sony, Target, Home Depot, UPS, even Victoria couldn’t keep the Secret.

The list:

http://www.idtheftcenter.org/images/breach/DataBreachReports_2014.pdf

This article will tell you how to stay off.

What Has Already Been Tried

First let’s have a look at what’s already being done.

I. Firewalls / Intrusion Detection

The perimeter has shattered.  Firewalls won’t stop someone who has credentials–attacks within the interior of a network.

“Myth: Firewalls make your data secure.  In fact, 40% of Internet break-ins occur in spite of a firewall being in place.“

Data Security Challenges – Oracle9i Security Review

II. Stong Authentication / Multi-factor Authentication / Single Sign-on

Often times bad things are committed by those with proper credentials.  Do not base your entire defense on the front door.

“Neither top secret clearance, sophisticated authentication nor the most advanced encrypted information systems can necessarily stop an intended breach action. These security procedures are not designed to detect real-time actions and anomalous business processes from authorized personnel. These practices are just the “moat around the castle” approach upon which most current cybersecurity technologies are based. Current national security breaches clearly show we need to do more.”

Is Cyber Security an Inside Job? – Larry Karisny – Digital Communities

III. Antivirus Software

Doesn’t stop attacks in-flight.  By the time a new virus has been identified, two more have spawned.

“In the bigger picture, furthermore, the anti-virus software was irrelevant, contends Chester Wisniewski, a senior security advisor at anti-virus vendor Sophos. “A smart attacker in a targeted environment will always bypass your anti-virus,” he says, and especially if they’re trying to take down a retailer the size of Home Depot.“

Analysis: Home Depot Breach Details – Mathew J Schwartz – Bank Info Security

These practices aren’t necessarily wrong, but they aren’t fixing the problem either.

The Problem

So what exactly is the problem?

A determined attack will gain access to your network – count on it.  It’s impossible for you to harden every entry point.  Find a way to minimize damage once the inevitable unauthorized entry occurs.

“Organizations should stop thinking about breach prevention, accept their going to be breached, change their mindset, and think about how they will protect and store their data.”

Stop Worrying About Data Breach Protection – Info Security Magazine

The Solution

You must boost efforts across the following:

I. Authorization

The access controls commonly used today are inadequate.  Let’s take a prime example:  How did a low-level, government contractor download terabytes of highly sensitive data from the NSA?

“Organizations that lack these controls are vulnerable to attacks waged by individuals who have legitimate accounts on the network but seek to misuse their access for malicious purposes. This risk, known as the “insider threat” is one of the most insidious causes of data breaches.“

How to avoid the five most common causes of data breaches – Mike Chappel – Certification Magazine

Add mandatory access control checks to all interfaces connected over Internet – including those downstream of secured.

II. Audit trail

If an action is important enough to guard with a policy enforcement point, it should be logged.

“The most important step that you can take to protect your organization against improperly configured access controls is to perform regular auditing.”

How to avoid the five most common causes of data breaches – Mike Chappel – Certification Magazine

Log the resource, operation, subject id, ip, location, time, date and result.

III. Periodic Review

Circulate daily reports.  Think about the results.  Devise heuristic algorithms to detect anomalies automatically.

IV. Confidentiality

Encryption enabled should be the default setting for ALL network connections – even test environments.  Don’t worry about the cost.  Consider it cheap insurance.

“In the aftermath of security breaches at Target, Home Depot, and JP Morgan Chase, executives are reexamining their data breach risks. Hacksurfer reports on a recent survey of IT professionals that found 53 percent of organizations were investing more in data security after these high-profile cyber attacks.”

In Data Security, Compliance Isn’t Enough – Max Schleicher – TechInsurance

Encrypt data in-flight and sensitive data at rest.  Hash passwords.

by Shawn McKinney

ABAC – Where are the Functional Specs?

As a security architect I have long-awaited the means to express authorization policies using dynamic constraints – in a standard way. Over the years there have not been many models to choose from.

First came A Resource Access Decision Service, which had promise, but departed with CORBA.

Next came eXtensible Access Control Markup Language (XACML).  Some believe it dead, and there are those who continue to promote.  The jury is out.

What do you think about XACML?

Now the buzz is Attribute-Based Access Control (ABAC).

Blurring the lines, supposedly XACML implements ABAC, because attributes combine with decisions.

There are commonalities across the three models:

  1. Grammar to express very fine-grained access control policies.
  2. Rules containing variables captured from subjects and resources.  Facts such as location, time and date included.
  3. Adjudication when rules combine or clash.
  4. Separation into multiple components, e.g. Policy Enforcement Point (PEP), Policy Decision Point (PDP), Policy Information Point (PIP).

The promise is reuse.

So where are the functional specs?  I must understand and share.

“Despite the clear guidance to implement contextual (risk adaptive) role or attribute based access control ABAC, to date there has not been a comprehensive effort to formally define or guide the implementation of ABAC”
NIST – ATTRIBUTE BASED ACCESS CONTROL (ABAC)

Ruh roh.

Until formal specifications are drafted, ABAC is useless because it’s non-standard and/or proprietary.

Back to square one – awaiting an industry standard dynamic authorization model.

by Shawn McKinney

Using Roles for Access Control is not RBAC

I hear this kind of statement all the time:  ‘We use Roles/Groups for access control in our systems and applications so we’re RBAC’.

My response is an emphatic:  ‘No – using roles for access control is not Role-Based Access Control!’

The first is an anti-pattern, the second a best practice.  Let me explain.

RBAC is not a generic term.  It refers to a specification, ANSI INCITS 359, with explicit instructions to implement.  There are many posts that offer detailed explanation – including:

https://directory.apache.org/fortress/user-guide/1-intro-rbac.html

To be considered RBAC compliant an access management system, at a minimum, supports the following entities: Users, Roles, Permissions (mapping between objects and operations) and, most important – Sessions.

Sessions are the context for which role activation occurs.  Just because a role has been assigned, does not mean it should be included into a particular access control decision.

This is in keeping with the principle of least privilege:  Only give the user the power needed to complete their job at any particular point in time – and no more.

Doing this satisfies a multitude of requirements and we’ll talk about some in future posts.

So unless your access control system supports the session contextual object – stop calling it RBAC.

But there’s much more to it than that.  RBAC specification defines the interfaces necessary for CRUD and interrogation operations.  One of the most important:

userPermissions(User)

This returns all permissions authorized for a user via their role assignments.  And another:

authorizedPermissionUsers(Permission)

Crucial during audits – which users have access to a particular system resource?  If you cannot answer this question your system lacks integrity.  Many access management systems cannot accomplish these basic operations.

RBAC also defines the interface used during runtime policy enforcement operations.  For example:

sessionPermissions(Session)

This returns all permissions authorized for a user via their role activations.  Used by apps to cache entitlements during runtime.  Without the Session entity it cannot be done.   If yours cannot do this – stop calling it RBAC.

Finally there is this:

Placing roles within the access control decision paints you into a corner.  This operation usually looks something like:

isUserInRole(RoleName)  <— this is ok for coarse-grain but not fine-grained authZ

What if the roles change?  Every change requires (some variation of) a recompile and redeployment of the application.  Worse, you will need to create too many of them which pollutes your system and complicates the administration processes.

There is a better way – use a permission semantic:

checkAccess(Session, Permission)

This allows the policy enforcement point to be decoupled from the policy decision point.  If the roles needed to access that resource change, the application doesn’t.

If your access management system does not do these things – stop calling it RBAC!

More to come….

by Shawn McKinney

A Newcomers Perspective on ApacheCon Europe – 2014

It’s one am and my last night in Budapest.  Its been six days since arrival yet for some reason I’m still jet-lagged and jolt awake in the middle of the night – once again.  An over-stimulated brain can’t manage to fall back asleep due to the inertia gathered during ApacheCon.  This affords time to reflect and write.

I’m the new kid on the block having just been voted as a committer into the Apache Directory project.  A colleague, Emmanuel Lecharny, invited me to co-present about Fortress, which is the reason for being here.

I’m happy because its been a good week for an open source addict.  New alliances have been formed along with new technologies learned – but I’m getting ahead of myself.

A few months ago the decision was made to move Fortress into the Apache Directory Project.  This move was not taken lightly.  OpenLDAP has been a good home and there were reasons to stay put.  First, it’s a product that offered an excellent example in which to follow.  Second, its project team gave sound mentorship.  Finally, moves such as these are disruptive for the community and can burn bridges.

But it was time to move on.  I needed help: Fortress requires the development processes and resources of ASF in order to gain traction.

I worried that my status as newcomer would place barriers to a successful outcome.  Being no stranger to tech circles gives awareness that many (most?) communities are insular (not built here syndrome) and require long periods before trust and support are established.  Opinions of newcomers are not trusted and attitudes must be kept in check lest they offend the others – especially the leaders.  I have no time for this kind of nonsense.

During my travel to Budapest these thoughts caused a bit of anxiety.  Would I, and more important – my product, fit in with the Apache way of doing things?  Would joining the Apache Directory Project help or hurt objectives?  I thought I knew the answer to these questions but wasn’t certain.

From the outset, during the opening keynotes, Rich Bowen set the tone. His laid-back style and no-nonsense approach of engaging the audience repeatedly struck the chord of fellowship and collaboration.  We’re part of something that is bigger.  Exclusiveness runs counter to that philosophy and risks spoiling the overall objectives of building strong communities and quality software.

Those first moments provided the realization that the right move had been made.  This place (Corinthia Hotel) would prove to be fertile ground for innovation and collaboration.  Creativity was everywhere – in the sessions (of course), the corridors and atriums, at the dining tables, and spilling out into the streets – even once whilst soaking at the thermal pools.  Innovation and collaboration could not be stopped.  This is the point of such a conference, but the magnitude astounded me.

The details are not important.  I felt welcomed, respected and treated as equal by the others.

I am not so naïve as to believe the ASF is immune to the political intrigue weighing down other large technological organizations.  As humans we can’t help but harbour hidden personal agendas and vendettas.  But there’s something different going on here. Not sure I can place a finger on it just yet, call it an intuition.

As I listened to the closing keynotes on Wednesday evening, and despite a natural inclination to be cynical of such sentiments, I could not help but feel a surge of pride at being part of this Apache movement.  I have found a new home – and good things will happen here.

*yawn* now I can return to sleep… 🙂