The Extended Domain Concept

One interesting problem that comes up during the course of security architecture is the concept of domains and how those domains interact with each other.  A simple example is shown in the figure below.

The figure depicts a few security policies (SA1, SA2, and SA3) along with some policy domains (domain 1, domain 2, domain 3).  The users A, and B belong to domain 1 and the users X and Y belong to domain 2.  For the above scenario, the following is true

• If user A wants to talk to user B, they must conform to security policy 1
• If user X wants to talk to user Y, they must conform to security policy 2
• domain 1 and domain 2 are sub-domains of domain 3
• If a user in domain 1 wants to talk to domain 2, they must conform to the security policy 3

Domains can generally interact with their environment in several different ways. For example, a domain could follow the example above where inter-domain communication is governed by a policy of the super domain.  In other cases, domain communication could be facilitated by a trusted third party.  This is similar to the current certificate authority system (if clients were also using certificates to validate their identity). 

One concept that I like in this space is that of the extended domain policy.  This policy is generally used when facilitating communication between a domain of stricter policies with that of a weaker one.  In this case, the domain with the stronger policy extends their domain into the weaker domain policy, only allowing communication to be facilitated via that broker.

Being a Canadian citizen, a nice way to illustrate this is to compare and contrast airport customs between Canada and the US.  When I travel to the US from Canada, I pass US customs in Canada.  This is a great example of the extended domain concept at work.  The US, believing their security requirements are much greater than Canada, will not let you board a plane destine for the US without first authorizing you.

Canada, on the other hand, acts more like a traditional inter-domain policy association.  Canada enforces it's controls at it's own border.

In the business world, I think that the extended domain concept is an important one.  One use case would be a corporate entity that owns several subsidiaries.  Using the extended domain model, the entity could enforce strict control over communication into it's network by deploying trusted agents in each subsidiary to facilitate communication.

 **Image taken from the book: Enterprise Security Architecture - Nicholas A Sherwood

SABSA Chartered Security Architect - Foundation Certificate Achieved!

A few months ago, I decided to attend SABSA training.  For a while, it had been something on the radar.  I wanted to find a good, recognized certification that spanned both architecture and security. SABSA fits the bill quite perfectly.

The course I attended was taught in Winnipeg of all places, and lead by the great Michael Legary.  Due to some administrative problems on a client end, there ended up being only 2 of us in the course.  This worked out great as we were able to explore in more detail the various sections and really work to apply the concepts to our current positions.  From a professional services perspective, I was interested in how to apply these concepts to our project delivery.  SABSAs focus on creating controls/solutions that are both traceable and justifiable in business context is, in my opinion, critical to the success of any project.

In case, at this point, you are wondering what SABSA actually is, please allow me to fill in some details.

SABSA stands for Sherwood Applied Business Security Architecture.  It is a methodology for developing business-driven, risk and opportunity focused enterprise security & information assurance architectures.  It is comprised of a number of frameworks, models, methods and processes.

The SABSA methodology focuses on delivering the following features:

- It is business-driven in nature
- It is risk focused (both from a threat and opportunity standpoint)
- It is comprehensive (and thus can be scaled from point areas to enterprise wide)
- It is modular (you don't have to big-bang this approach)
- It is open source (well, kinda ;) )
- It is auditable (this is the entire point, justify what you are doing)
- It is transparent (two-way traceability)

There is a ton to SABSA. If you are interested in finding out more, please take a gander at the SABSA Whitepaper (registration required).

One thing I will say, it was a TOUGH exam.  I think the level of abstractions that are dealt with in enterprise architecture are hard to grasp over the course of 5 days.  I look forward to spending a significant amount of time digesting the course material and integrating it into my day job.

Am I now a starfish?

In his book, Management 3.0, Jurgen Appelo makes a startling comparison between starfish and managers.

"For example, the ancestors of brainless starfish had a brain. But starfish don’t, and nobody knows why…. (Some believe the same applies to managers.)"

While he was probably just trying to make a joke, my experience suggests that the best jokes are generally ones based in reality.  When I look at my personal career, I am fortunate enough to boast that I have had mostly good managers.  I have been able to relate to my managers.  Most of them have put some effort into my personal and professional development.  They have always been able to provide timely advice and guide me in the right direction (or maybe in their self-image?). 

During all this time, however, my view of management has always been along a singular theme, the theme of the starfish.  How do these people get into these positions?  Why don't they use their brains?  Why does everything seem so dis-jointed? Why are they not addressing the problems that really matter?

Reading this book has caused me to spend a fair bit of time self-reflecting.  When I look back at years past, I always wanted things to be orderly.  I wanted to be able to explain what was going on in simple terms.  After all, if you can't break down a problem into simple components, then you don't really understand it… right?  The book would classify what I was attempting to do as reductionism.

"The approach of deconstructing systems into their parts and analyzing how these parts interact to make up the whole is called reductionism".

What I learned is that while these concepts are good to understand how an airplane works, it does little to help explain how complex systems such as corporates work.  Things are really not that simple, and can't always be explained in simple terms.

In a lot of ways, I am really, REALLY glad that the author took the time to write this book.  He approaches the concepts of management like I would (or at least, would hope to).  He spends a lot of time talking about systems theory, explaining just enough of the core concepts to get his point across.  He relates management of people to that of complex systems.  And luckily, work has been done over the years into how to describe, manage, and interact with complex systems.  So why not try and apply those concepts to management?

The application of those concepts, combined with years of experience I'm sure, has led to what is termed the "Management 3.0 model".  There 6 views to this model.

1. Align Constraints
2. Develop Competence
3. Empower Teams
4. Grow Structure
5. Energize People
6. Improve Everything

The last chapter is really the icing on the cake for this book, and probably puts it among the top of ones that I have read.  The author goes out of his way to claim that his model is probably incorrect.  The point, ultimately, is that there is no one way to view/manage complex systems.  The system functions as a will, all you can do, as management, is hope to contribute a little to its direction.  If you adopt agile approaches, focus on using appropriate (for your environment) tools and processes, and have a little bit of luck, you might just be successful at it!

As always, I highly recommend you check out this book.  You can start at the authors website.

Recently, I have been promoted to Manager of the Application Infrastructure group at Hitachi Solutions Canada.  I look forward to the new challenge.