Architecture or Engineering?

It’s not exactly the great debate. There may not be that many folks on the planet who care what we call this emerging discipline in which I’m involved? Still, those of us who are involved are trying to work through our differences. We don’t yet have a clear consensus definition. Though I would offer that a consensus on the field of security architecture is beginning to coalesce within the practitioner community. (call the discipline what-you-will)

One of the lively discussions here at the SANS What Works In Security Architecture is, “What do we call ourselves?”

Clearly, there are at least two threads. One thread (my practice) is to call what I do “Information Security Architecture”. The other thread is “Systems Security Engineer”.

I read one of the formative documents from the “Systems Security Engineer” position last month (it’s not yet announced; so I’m sure if I can say from whom, yet?)  And what was described was pretty close to what I’ve been calling “Security Architecture”.

Here’s the interesting part to me: that no matter the name, collectively, we’re realizing that we require this set of functions to be fulfilled. I’ll try to make a succinct statement about the consensus task list that I think is emerging:

  • Study of a proposed system architecture for security needs
  • Discussion with the proposers of the system (“the business” in parlance) about what the system is meant to do and the required security posture
  • Translation of required security posture into security requirements
  • Translation of the security requirements into specific security controls within a system design
  • Given an architecture, assessing the security risk based upon a strong understanding of information security threats for that organization and that type of architecture

In some organizations, the security architect task is complete at delivery of the plan. In others, the architect is expected to help design the specific controls into the system. And then, possibly, the architect is also responsible for the due diligence task of assuring that the controls were actually implemented. In my experience, I am responsible for all of these tasks and I’m called a “Security Architect”.

From the other perspective, the role is called “Systems Security Engineer”. And, it is also expected that the upfront tasks of discussion and analysis are performed by a security architect who is no longer engaged after delivery of the high level items (listed above).

That’s not how it works in my world. And, I would offer that this “leave it after analysis” model might lead to “Ivory Tower” type pronouncements. I’ll never forget one of my early big errors. I was told that “all external SSL communications were required to be bi-directionally authenticated” OK – I’d specify that for every external SSL project. Smile

Then projects started coming back to me, sometimes months later, having been asking for bi-directional authentication, and being told that on the shared java environment,”no can do”.

The way that this environment was set up, it didn’t support bi-directional authentication at an application granularity. And that was the requirement that I had given, not once but several times. I was “following the established standard”, right?

I submit to your comment and discussion that

  1. There’s more than one way to achieve similar security control (in this case, bi-directionally authenticated encrypted tunnels)
  2. It’s very important to specify requirements that can be met
  3. A security architect must understand the existing capabilities before writing requirements.

Instead of ivory tower pronouncements, if I believe that there is a technology gap, my job is to surface and make the gap as transparent as possible to the eventual owners of the system under analysis (“the business”).
How can I do this job if all I have to do is work from paper standards  and then walk away. Frankly, I’d lose all credibility. The only thing that saved me early on was my willingness to admit my errors and then pitch in wholeheartedly to solve any problems that I’d help create (or, really, anything that comes up!)

Some definitions for your consideration:

  • Architecture: the structure and organization of a computer’s hardware or system software
  • Engineering:  the discipline dealing with the art or science of applying scientific knowledge to practical problems

Engineers apply say, cryptography, an algorithm to solve problems. Architects plan that cryptography will be required for a particular set of transmissions or for storage of a set of data.

At least, these are my working definitions for the moment.

So, after listening to both sides, in my typically equivocal manner, I’m wondering if this role that I practice is really a good and full slice of architecture, combined with a good and full slice of engineering?

Practitioners, it seems to me from my experience, need both of these if they are to gain credibility with the various groups with whom they must interact. And “no”, I don’t want to perpetuate any ivory towers!

Send me your ideas for a better name, a combinatorial name. what-have-you



from Las Vegas airport

What is this thing called “Security Architecture”?

What is this thing called “Security Architecture”?

In February 2009, while I was attending an Open Group Architecture Conference in Bangalore, India, several of us got into a conversation about how security fits into enterprise architecture. A couple of the main folks from the Open Group were involved (sorry, I don’t remember who). They’d been struggling with this same problem: Is high level security participation in the process architectural, as defined for IT architecture?

Participants to that particular conversation had considered several possibilities. Maybe there is such a thing as a security architect? Maybe security participation is as a Subject Matter Expert (SME)? Maybe it’s all design and engineering?

Interesting questions.

I think how an organization views security may depend on how security is engaged and for what purposes. If security is engaged at an engineering level only,

  • “please approve my ACLs”
  • “what is the script for hardening this system? Has it been hardened sufficiently?”
  • “is this encryption algorithm acceptable?”
  • “is this password strength within policy?”
  • etc.

Then that organization will not likely have security architects. In fact (and I’ve seen this), there may be absolutely no concept of security architecture. “Security architecture” might be like saying, “when pigs fly”.

If your security folks are policy & governance wonks, then too, there may not be much of a security architecture practice.

Organizations where security folks are brought in to help projects achieve an appropriate security posture and also brought in to vet that a proposal won’t in some way degrade the current security posture of the organization, my guess is these are among the driving tasks for developing a security architecture practice?

However, in my definition of security architecture, I wouldn’t limit the practice to vetting project security. There can be more to it than that.

  • security strategy
  • threat landscape, (emerging term: “threatscape”)
  • technology patterns, blueprints, standards, guides
  • risk analysis, assessment, communication and decisions
  • emerging technology trends and how these affect security

A strong practitioner will be well versed in a few of these and at least conversant in all at some level. Risk analysis is mandatory.

I’ve held the title “Security Architect” for almost 10 years now. In that time, my practice has changed quite a lot, as well as my understanding, as my team’s understanding have grown. Additionally, we’ve partnered alongside an emerging enterprise architecture team and practice, which has helped me understand not only the practice of system architecture, but my place in that practice as a specialist in security.

Interestingly, I’ve seen security architecture lead or become a practice before enterprise architecture! Why is that? To say so, to observe so, seems entirely counter-intuitive – which is where the Open Group folks were coming from, I fear?. They are focused deeply on IT architecture. Security may be a side-show in their minds, perhaps even, “oh, those guys who maintain the IDS systems”?

Still, it remains in my experience that security may certainly lead architecture practice. Your security architects will have to learn to take a more holistic approach to systems than your development and design community may require. There’s a fundamental reason for this!

You can’t apply the right security controls for a system that you do not understand from bottom to top, front to back, side to side, all flows, all protocols, highest sensitivity of data. Period.

Security controls tend to be very specific; they protect particular points of a system or flow. Since controls tend to be specific, we generally overlap them, building our defense out of multiple controls, the classic, “defense-in-depth”. In order to apply the correct set of controls, in order not to specify more than is necessary to achieve an appropriate security posture, each control needs to be understood in the context of the complete system and its requirements. No control can be taken in isolation from the rest of the system. No control is a panacea. No control in isolation is unbreakable. The architectural application of controls builds the appropriate level of risk.

But project information by itself isn’t really enough to get the job done, it turns out. By now I’ve mentored a few folks just starting out into security architecture. While we’re certainly not all the same, teaching the security part is the easy part, it turns out (in my experience). In addition to a working understanding of

  • Knowledge of the local systems and infrastructures, how these work, what are their security strengths and weak points
  • The local policies and standards, and a feel for industry standard approaches
  • What can IT build easily, what will be difficult?
  • Understanding within all the control domains of security at least at a gross level
  • Design skills, ability to see patterns of application across disparate systems
  • Ability to see relationships across systems
  • Ability to apply specific controls to protect complex flows
  • Depth in at least 2 technological areas
  • A good feel for working with people

Due to the need to view complex systems holistically in order to apply appropriate security, the successful security architects quickly get a handle on the complexity and breadth of a system, all the major components, and how all of these will communicate with each other. Security architects need to get proficient at ignoring implementation details and other “noise”, say the details of user interface design (which only rarely, I find, have security implications).

The necessity of viewing a system at an architectural level and then applying patterns where applicable are the bread and butter of an architectural approach. In other words, security must be applied from an architectural manner; practitioners have no choice if they are to see all the likely attack vectors and mitigate these.

Building a strong defense in depth I think demands architectural thinking. That, at least is what we discovered 9-10 years ago on our way to a security architecture practice.

And, it’s important to note that security architects deal in “mis-use” cases, not “use cases”. We have to think like an attacker. I’ve often heard a system designer complain, “but the system isn’t built to work that way”. That may be, but if the attacker can find a way, s/he will if that vector delivers any advantage.

One my working mantras is, “think like an attacker, but question like a team mate”. In a subsequent post, I’d like to take this subject up more deeply as it is at the heart of what we have to do.

And, as I wrote above, because of this necessity to apply security architecturally, security architects may be among your first system architects! “Necessity is the mother of invention”, as they say.

Security architecture may lead other domains or the enterprise practice. I remember in the early days that we often grumbled to each other about having to step into a broader architecture role simply because it was missing. In order to do our job, we needed architecture. In the absence of such a practice, we would have to do it for projects simply because we, the security architects, couldn’t get our work completed. We’d step into the breach. This may not be true in your organization? But in my experience, this has been a dirty little secret in more than one.

So, if you’re looking to get architecture started in your IT shop, see if the security folks have already put their toes in the water.

In the last year, I believe that a consensus is beginning to emerge within the security industry about security architecture. I’ve seen a couple of papers recently that are attempts to codify our body of practice, the skill set, the process of security architecture. It seems an exciting and auspicious time. Is security architecture finally beginning to come of age?

The time seems ripe for a summit of practitioners in order to talk about these very issues. It’s great that SANS is pulling us together next week in Las Vegas, What Works In Security Architecture. Yours truly will be speaking a couple of times at the summit.

Please join me next week, May 24-26, 2010 in Las Vegas. Engage me in lively and spirited dialog about security architecture.



What’s Wrong With Customer Support?

I know that it’s been a while since I’ve posted. Let me apologize for that. I’ve got a lot of topics that I want to start covering here soon. Stay tuned.

Still, this morning’s reply from Intuit customer support was just too rich to pass up. Let me offer this little laugh to you to brighten you day. And then, I want to say a few words about why these interchanges are endemic to customer support as practiced by most companies.

I’ve heard support folks called “case closing machines”. Not very nice. But unfortunately, far too true. These are the metrics upon which customer support are rated: how many support cases can be moved through the queue within a time period.

The result of this rating, of course, is that the support person is far more interested in responding quickly to dispose of a request than in actually understanding what has been requested. And that, I find, wastes everyone’s time.

Let me give some context. I use Quicken 2oo7 on Macintosh for my home accounting. I’ve been a Quicken and Intuit customer for years. I was having trouble updating transactions to account from my financial institution. Heck, first thing to do is always update the software, right?

OK. I ran the R2 installer and got a weird error message claiming that I had “no valid copy” of the the software. Huh? Since I was in a hurry (first mistake!), I fired off a support ticket. 10 minutes later, I checked the running version of my software and low and behold, I’d already installed R2. Uh, oh! Bad ticket, no need for support.

Well, there wasn’t any way to recall the issue. So I let it grind through support while I installed the R3 updater successfully. (this didn’t solve the original problem, unfortunately. but that’s another story)

When I received the response to my ticket from Quicken, at first I was just going to ignore it. But the activist in me just can’t let lie!

I wrote back a quick note suggesting that the error message in the R2 updater might be just a little misleading.

Here’s my reply to Quicken Support. I’ll follow that with the first couple of lines of the second reply from Quicken Support:

“Yes – I figured your suggestion out about 15 minutes after putting in
the ticket. Sorry about that.

But, I would suggest that your error message could say something of the

“your quicken is already upgraded to R2”

Rather than “no valid quicken found” (or whatever the error says).

these are very different messaging. I would have had no need to file a
ticket (that’s money in intuit’s pockets, yes?)

Your programmers and QA staff need to do better, I think!


I’ll admit that my suggestion might be a bit terse. It does say, I hope clearly, that I found my solution, yes? I even apologize for the submitting the ticket: “Sorry about that”

then I go on to make a suggestion, “Change your error message. It’s misleading”

Here’s what I got back from “Karuna, Quicken Customer Care”:

“Brook, in this case I would advise you to uninstall and reinstall Quicken using the download link which I am providing you with. The download link contains the complete software with the updated patch. Please follow the steps mentioned below to uninstall Quicken…”

The email interchange goes on in detail on how to accomplish the reinstallation of Quicken 2007, including a download of the entire installer! If I had followed these instructions, it would have wasted hours of my time; I wouldn’t be writing this post, smile.

It is true that filing the issue was my mistake; there wasn’t anything really wrong.

My mistake was based upon a very poorly written error message in the R2 installer for Quicken 2007 which suggested that I had no valid copy of Quicken 2007. Which, of course, I do**.

Intuit support didn’t understand my note – probably the person working the issue didn’t really read it? Can you spell “scan”?

My response to Intuit required no reply whatsoever. Rather I suggested action on the part of Intuit Product Management and perhaps the development teams, should there be merit in my suggestion.
Quite obviously, keeping ridiculous metrics like “cases closed/time period” forces a support team to actually waste huge amounts of time sending useless and inappropriate replies to people who don’t need them and can’t use them. All in the  name of productivity.

Most companies do it this way. It’s rare that I actually get a first reply that is on target demonstrating true understanding! Support don’t actually read what’s been written. I get asked all the time to “please supply the version and machine information” which I have already very carefully listed in the request. How absurd is that?

Support assume:

  • the incompetence of the request
  • the poor articulation of the requester

Support prioritize:

  • speed of delivery over understanding
  • delivering an answer, any answer
  • the first lines of the question (which are often only context)
  • any answer that can found in existing the knowledge base, no matter how inappropriate

If the support person had only truly read what I wrote s/he would have fully known that:

  • I didn’t need a reply
  • I had made a suggestion to be passed to Product Management
  • my problem was solved before the first reply from Quicken last week

Scanning the email (esp. if the scanner’s English is a 2nd or 3rd language) is highly prone to this kind of misunderstanding.


I think I’ll try to find out who’s the executive in charge of Intuit’s support operations and talk to that person. Because this is just too ridiculous to let go. We in the software industry need to get a lot more professional if customers are going to trust us.

Treating our support people as “case closing machines” is demeaning and dehumanizing. Instead of valuing and training problem solvers, we’ve created a situation whereby the competent use the support role only as a stepping stone on the way to another position. Who’s left behind? Those with low self-esteem, low expectations, those who don’t care about the job. Is that who you want responding to your customers?

And, of course, these sorts of email interchange and frustration go back and forth every day wasting everyone’s time with useless solutions to problems that don’t exist.


/brook schoenfield

**I pay for my software – it’s ethical. And, as John Caron used to say to me, “People don’t pay for software. They register the software because of the bugs for which they’ll need support” Tee, hee. all too true, John.

Missed Points, Wrong Message?

Today, as every day, I was bombarded with articles to read. You, too?

Today, Testing for the Masses: More affordable assessment services reveal a new focus on application security caught my eye.

As some of my readers may know, I’ve spent a lot of time and effort on re-creating the customer web application security testing viewpoint. And, of course, Markus and I often don’t agree. So, I trundled off to read what he’d opined on the subject.

Actually, it’s great to see that ideas that were bleeding edge a few years ago are now being championed in the press!

* Build security in the design
* Code securely
* Verify both the design and the code

The “design” part of the problem requires reasonable maturity of a security architecture practice.

And, web application code must be tested and fixed before deployment, just as this article suggests. All good. If we could achieve these goals on a broad scale it would be a much better world that what we’ve got, which has been to deploy more than 100 millon lines of vulnerable code to the web (see Jeremiah Grossman’s white papers on this topic)

Further, the writers suggested that price points of web application testing tools must fall. And here’s where the ball got dropped. Why?

The question of price is related to one of the main limitations on getting at least the simple and egregious bugs out of our web code.

The tool set has until recently been made for and focused to people like Markus Ranum – security experts, penetration testing gurus. These tools have emphasized broad coverage and deep analysis. And that emphasis has been very much at the expense of:

* tool cost
* tool complexity
* noisy results that must be hand qualified by an expert

There aren’t that many Markus Ranum’s in the world. In fact, as far as I know, only one! Seriously, there are not that many experienced web application vulnerability analysts. My estimate of approximately 5000 was knocked down by some pundit (I don’t remember who?) at a SANs conference at which I was speaking. His guesstimate? 1500. Sigh. Imagine how many lines of code each has to analyze to even make a dent in those 100 million lines deployed.

Each of the major web application vulnerability scanners assumed that the user was going to become an expert user in the tool. User interfaces are complex. Setting the scope and test suite are a seriously non-trivial exercise.

And finally, there is the noise in the results – all those false positives. These tools all assume that the results will be analyzed by a security expert.

Taken together, we have what I call the “lint problem”. For those who remember programming in the C language, there is a terrifically powerful analyzer called “lint”. This tool can work through a body of code and find all kinds of additional errors that the compiler will miss. Why doesn’t everyone use lint, then? Actually, most C programmers never use lint.

Lint is too hard and resource intensive to tune. For projects that are more complex than one of two source files, the cost of tuning lint far out weighs it’s value. So, only a few programmers ever used the tool. On a 3 month project, just about the time the project is over is when lint is finally returning just the useful results. Not very timely, I’m afraid.

And so, custom web application vulnerability testing has remained in the hands of experts, people like Markus Ranum, who, indeed, makes his living by reviewing and fixing code (and rumour has it, a very good living, indeed).

So, of course, Markus probably isn’t going to suggest the one movement that will actually bring a significant shift this problem.

But I will.

The vulnerability check must be put into the hands of the developer! Radical idea?

And, that check can’t be a noisy, expert driven analysis.

* The scan must be no more difficult to run than a compiler or linker. (which are, after all, the tools in use by many web developers every day)
* The scan should integrated seamlessly into the existing workflow
* The scan must not add a significant  time to the developer’s workflow
* The results must be easy to interpret
* The results must be as accurate as a compiler. E.g., the developer must be able to trust the results with very high confidence

Attack these bugs at the source. And, to achieve that, give the developer a tool set that s/he can use and trust.

And, the price point has to be in accordance with other, similar tools.

I happen to know of several organizations that have either experimented with this concept or have put programs into place based on these principles (can’t name them, sorry. NDA) And guess what? It works!

Hey, toolmakers, the web developer market is huge! There’s money to be made here, folks.

Markus, I think you missed a key point, and are pointing in the wrong direction (slightly)



Executive Information Security Risk Dialog

Ah, sigh, Marcus and I almost never agree! And, this often a matter of lexicon and scoping. In this case, Marcus stays away from the thorny issue of risk methodology. But this, I think, is precisely the point to discuss.

Think about the word “risk”. How many definitions have you seen? The word is so overloaded and imprecise (and undefined in Marus’ Rant) that saying “risk” without definition will almost surely undermine the technical/C-level management dialog!

I would argue that the reasons for failure of the security to executive risk dialog have less to do with C-level inability to grasp security issues than it has to do with our imprecision in describing risk for them!

Take Jack Jones. When at Nationwide, he found himself mired within Ranum’s rant. I’ve been there, too. Who hasn’t?

To solve the problem and feel more effective, he spent 5 years designing a usable, repeatable, standardized risk methodology. (FAIR. And yes, you’ve heard me rant about it before)

Jack described to me just how dramatically his C-level conversations changed. Suddenly, crisp interactions were taking place. What changed?

I see the failure of the dialog has having these components:

  • poor risk methodology
  • poor communication about risk
  • not treating executives as executives

Let me explain.

Poor risk methodology is the leading cause of inaccurate and unproductive risk dialog. When we say “risk” what is our agreed upon meaning?

I’ve participated in many discussions that treat risk as equivalent with an open vulnerability. Period.

But, of course, that’s wrong, and actually highly misleading. Is “risk” a vulnerability added to some force that has motivation to exercise the vulnerability (“threat” – I prefer “threat agent” for this, by the way)? That again is incomplete – but that is often what we mean when we say information security risk. And, again, it’s wrong.

In fact, as I understand it, threat can be conceived as the interaction between the components that create a credible threat agent who has sufficient motivation and access in order to exercise an exposed vulnerability. This is quite complex. And, unfortunately, the mathematics involved may be beyond many security practitioners?> Certainly, when in the field these mathematics may be too much?

Most of us security professionals are pretty good on the vulnerability side. We’re good at assessing whether a vulnerability is serious or not, whether its impact can be far-reaching or localized,  how much is exposed. It seems to me, that it’s the threat calculation that’s the difficult piece. I’ve seen so many “methodologies” that don’t go deep enough about threat. Certainly there are reasonable lists of threat agent categories. And, maybe the methodology includes threat motivation. Maybe they include capability? But motivation, capability, risk appetite, access? Very few. And how do you calculate these?

And then there’s the issue of impact. In my practice, I like to get the people close enough to business to assess impact. That doesn’t mean I don’t have a part in the calculation. Often times the security person has a better understanding of the potential scope of vulnerability and the threats that may exercise it than a business person. Still, a business person understands what the loss of their data will mean. However impact is assessed, it has a relationship to the threat and vulnerability side. Together these are the components of risk.

I think in this space, it probably doesn’t make sense to go into the various calculations that might go into actually coming up with a risk calculation? Indeed, this is a nontrivial matter, though I have made the case that any consistent number between zero and one on threat and vulnerability side of the equation can effectively work. (But that’s another post about the hour at an RSA conference presentation that helped me to understand this little bit of risk calculation trickery.)

In any event, hopefully you can see that expressing some reasonable indication of risk is a nontrivial exercise?

Simply telling an executive that there is a serious vulnerability, or that there’s a flaw in an architecture that “might” lead to serious harm waters down the risk conversation. When we do this, we set ourselves up for failure. We are likely to get “I except the risk”, or, an argument about how serious the risk is. Neither of these is what we want.

And this is why I mention “poor communication of risk” as an important factor in the failure of risk conversations. Part of this is our risk methodology, as I’ve written. In addition, there is the clarity of communication. We want to keep the conversation focused on business risk. We do not want to bog down in the rightness or wrongness of a particular project or approach, or an argument about the risk calculation. (And these are what Ranum describes) In my opinion, each of these must be avoided in order to get the dialog that is needed. We need a conversation about the acceptable business risks for the organization.

Which brings me to “treating executives as executives”. When we ask executives to come down into the weeds and help us make technical decisions we are not only inviting trouble, but we are also depriving ourselves and the organization of the vision, strategy, and scope that lays at the executive level. And that’s a loss for everyone involved.

I think we make a big mistake asking the executive to assess our risk calculation. We should have solid methodologies. It must be understood that the risk picture were giving is the best possible given information at hand. There needs to be respect from executive to information security that the risk calculations are valid (as much as we can make them).

No FUD! Don’t ask your executives to decide minor technical details. Don’t ask your executives to dispute risk calculations. Instead, ask them to make major risk decisions, major strategic decisions for your organization. Treat them as your executives. Speak to them in business language, about business risks, which include your assessment about how the technical issues will impact the organization in business terms.

I’ve been surprised at how my own shift with respect to these issues has changed my conversation away from pointless arguments to productive decision-making. And yes, Marcus, amazingly enough, bad projects do get killed when I’ve expressed risk clearly and in business terms.

Sometimes it makes business sense to take calculated risks. One of the biggest changes I’ve had to make as a security professional is to avoid prejudice about risk in my arguments. Like many security folk, I have a bias that all risk should be removed. When I started to shift to that, I started to get more real dialog. Not before.

So, Marcus, we disagree once again. But we disagree more about focus rather than on substance? I like to focus on the things that I can change, rather than repeating the loops of the past endlessly.



Architect Surprise!

Architect Surprise!

“Architect Surprise” is what I had last Thursday.

No, it’s not a new recipe. Nor is it a building whose structure is shocking. Although most certainly I was surprised enough to sit up and take notice.

I had been attending a series of security meetings where we agonize over the information security issues that are most on our minds.

I’ve been working with this group for 3-4 years. I find baring my security soul to peers and betters deeply helps my practice. And, if I’ve learned something, I’m happy to share any tidbits that I’ve gleaned so that we don’t all make my mistakes. Information security is just plain hard! (my 2 cents)

I can’t tell you who attends these meetings or who runs them.

Still, the facilitators are amazing professionals who work to help us enlighten each other. Let’s just say that it’s the CISOs (Chief Information Security Officers) or their direct reports for a lot of companies you’ve heard of and a few that maybe you haven’t – but they’re all at enterprise level. We have a strict “what is said in the room stays in the room” policy. And I intend to fully honor both the letter and spirit of that agreement.

I’m often the lone techie in the room. I’m not at all sure why these folks tolerate me? But they have been wonderfully open to me, and I deeply appreciate both their confidence, their help and in many cases, the friendship that has been given to me.

Thursday, we had a panel on “generation Y” in the workplace. An erudite and articulate group of folks was assembled to answer our questions. (Most of the usual attendees of the meetings are at least older than Gen-X, smile)

My architect surprise happened almost at the beginning. 2 of these folks, one of whom has been in the workplace for 3-4 years and another person that she recently helped to hire are “Solutions Architects” at a big insurance company.

Wow! At the company for whom I work, “Solutions Architect” is almost as high as one can go. technically.

So, I thought, maybe they’re just using this term in a really different way that I’m used to? I let it go and got on with the panel.

Then, later, it became clear that indeed, they probably did use the term “systems architect” as I know it. I don’t know what they mean by “solutions” and expect that there is some semantic difference?

However, even having someone straight from school (Masters, EE) fulfuill the role of architect I think is generally not a good idea.

I want to be clear that my worry has nothing to do with age, though level of experience is very key.

And here is why: I have long preached that systems architecture practice really requires someone to be deep in at least 2 technical areas. When I write “deep” I don’t mean “studied in school” or “majored” or “masters degree”.

I mean, “practiced successfully”.  I mean, deep, as in, understands an area fully to a core level of practice and broadly across most common cases.

And, I’m sorry, young readers – that kind of experience is very hard to get without a practicum. It takes years. I don’t think it’s easy to short-cut the process.

Not that there can’t exist the odd talent who gets deep early and quickly. The extraordinary does manifest.

But most of us mortals have to live and work to gain our depth.

Why at least two areas?

Because I have seen that something magical and unexpected happens after the second deepening. Even more so on the third, the fourth. Besides, with each area, the next gets easier and faster.

It is the ability to identify and make use of patterns. And patterns are the basis for systems architecture. Not rules. Not following guidelines (architects create these from use patterns) Patterns. Design patterns. Data flow patterns. Communications patterns. Security control patterns.

I have watched great engineers founder as architects. Not everyone is cut out for noting and using abstract patterns, for identifying and working through the relationships between system components.(but that’s a different post)

Systems architecture isn’t about code modules and interfaces. Although that is wonderful place to build (and deepen) design skills. It’s the “school of hard knocks” where I did a great deal of my learning. But systems architecture steps above that to a greater level of abstraction (and sometimes to a much greater level of complexity).

No, I wouldn’t  push my fresh-out-of-school recruits into an architect position. It’s not fair to them. And it’s not fair to the practice.

One of the panelists was delighted to have been given the chance to be an architect straight out of school. But I think she’s missing something important – her practicum that will set her free to design well, perhaps even innovatively.

I believe that systems architecture requires breadth and depth. This can only be won through time, successes, and the all important mistakes and missteps.



What’s Occurred in Web Years?

What’s Occurred in Web Years?

I was trying to explain to a colleague some of the sea change that has already taken place on the web (IMHO) – “Web 2.0” if you will?

I was explaining that the typical large enterprise (and really, many small ones, too) have become an intersection of clouds.

We used to use the image of the “good” inside protecting itself from the hostile (“bad”) Internet. The Internet was the cloud, the internal network a known and fixed space, “the network”. And, indeed, when I got started in Information Security, that is pretty much how things were.

But where I work, nobody knows all the networks that are interconnected. Acquisitions, test networks, global points of presence (POPs), all work to make a complex of interconnected networks. It’s too complex to hold in the mind. A mapping exercise some years ago revealed connections that nobody had documented – “discovered lands!”

In fact, the enterprise network seems a mini-internet or cloud that is probably less hostile than the Internet. But it’s certainly not trusted like the little “Class C” (anybody remember classed networks?) that I use to be responsible for where I knew everyone on the network and a lot of what they were using the network for.

But the enterprise cloud is not the only cloud at play.

Within the business eco-system are many similar interconnected network spaces of varying regulation and relationship, from close to pretty distant and untrusted. To be sure, a lot of these connect via the Internet. But certainly not all. Most enterprises have private connections with partners. The partners are literally cross-connected to the “internal” network.

There may be (should be?) network and other restrictions in place between the networks. Still, traffic flows and presumably some portion of that traffic is likely hostile (hopefully a minute portion, well monitored?)

The need to model business relationships via the network has caused an explosion of interconnected clouds.

Basically, the perimeter means much less than it once did – perhaps even “The perimeter is dead. Long live the perimeter!”

Coupled with this change has been the rapid growth of software tools on the network that model human relationship graphs and which allow a much greater degree of participation.

So, while the internal network has been growing in complexity and opening up to interconnections, usage patterns  (and business demand, it turns out) have been driving from inside to out.

These two forces have already occurred. And they happened, to my observation, faster than the growth of Web 1.0. Social networking seems to me to have taken off in months. The blogosphere has well been in place for several years. When is the last time you bought an expensive item about which you were uncertain without first checking online reviews and perhaps the blogosphere? I almost always (always?) do this before uncertain purchases.

What does this all have to do with security architecture?

These changes shift things fundamentally.

Network controls are now a tool – not the basis for one’s information security posture. We are using them around critical assets, but they no longer divide the “good” inside from the “bad” outside.

Meanwhile, data is moving out of the inner cloud and is a “must” for business agility. We can’t control our data by keeping our hot little security controls (“ACLs” – smile) around it.

The old security paradigm is obsolete. We need a new one.

And all this, in my opinion, transpired in web years while many of us were sleeping away building better network castles.



(from the Denver airport)

Another Synchronistic Coincidence

What’s the difference between influence and collaboration?

I might begin to believe that I’ve come to a conference of salespeople, not enterprise architects. Sheesh.

(I have nothing against influence by salespeople. No commercial organization can be successful without salespeople. Having once done sales, I have a deep appreciation for the profession; I’m not very good at sales)

When we sell, we “influence”. We have an idea which we are trying to get others to agree with, or product to buy.

And certainly, architects must be influential, persuasive. But I do not believe that “influence” is at the heart of architecture. Influence is a byproduct of successful collaboration. We hone the architecture until it meets the requirements. We incorporate stakeholders’ concerns. Selling is not the operative action, in my opinion.

Rather, I believe that what we architects do is synthetic, perhaps highly synthetic?

If we’ve done our job correctly, when our architecture is successful, we will need no pitch. Or, we must bring the bad news that requirements cannot be met, that tough decisions need to be made.

I just posted to this blog about the importance of forming and maintaining relationships based upon understanding, trust, and mutuality.

Since writing that post, I’ve been sitting in presentation after presentation by enterprise architects. And most of them have pointed to “influence” as a key factor of our practice. But none of them has used the word “collaboration”. None have spoken about relationship building, about understanding as a fundamental prerequisite to “influence”

I would fault the presenters at this conference with missing the point. Influence cannot be thought of by itself. It’s a product. Influence comes naturally from acquired trust and earned authority.

Otherwise, our work as architects is a one-way monologue. And I cannot understand how a monologue produces architecture in an enterprise.

I believe that it’s the interaction, both our influence and the understanding of the needs and influence of our stakeholders that drives the relationships that are fundamental to the acceptance of system architecture in the enterprise.

I can’t believe that I had just written about this subject?!? Synchronicity in action.


/brook from Bangalore, India

System Architecture: Fascinating People Forming Relationships

Fascinating People, Forming Relationships

I’m in Bangalore for a week or so. I’m here for a couple of purposes: I’m spreading the word about our new Application Vulnerability Assessment programs. And, I’m here to talk about Security Architecture as a practice, as a career. Our security department’s team here in Bangalore are wonderful engineers, young, full of energy, enthusiastic. But there aren’t any Security Architects here. So, our global security architecture practice is hampered by the lack of presence in this theater.

Hence, I’ve been here explaining, demonstrating, yes, stumping a bit.

I’ve been staying with a friend from work who’s here managing this team. He’s been hosting me in his home – I much prefer getting to know his family rather than staying in a hotel, no matter how plush the accommodations. A bed and a shower are about all I require. There’s no accounting for personal tastes, eh?

And, here’s where my story takes an interesting turn.

Traffic is tough in Bangalore. You’ll be crossing a congested bridge, and cars and especially motorcycles supposedly on the other side of the road will take one or more lanes out of your side, oncoming, willy, nilly. Driving lanes are not respected; as many vehicles as will fit side by side, with inches to spare, will be filled. Beware of any empty space, as it will be filled by vehicles trying to get a leg up, crowding to the “front” of the line. Though in this traffic, where exactly would be the “front”?

So, I’m happy to be driven by an expert in this traffic. And, our company does not allow staff posted to work here to drive. The company pays for a driver. The risk of accident is just too high. It’s cheaper to let a professional do the driving.

I’ve had a lot of interesting conversations with my host’s driver. And his story is what I want to share. Let’s call the driver Raju (to protect him and his privacy).

Ragu is a wonderfully sweet man, mid-thirties, dedicated to his family, hard working and conscientious. His driving, at least to my eyes in the rather chaotic and dangerous Bangalore traffic is highly professional, careful and as considerate as one can be here where traffic courtesy is taken as a sign of weakness of which to take advantage. The traffic here is scary to my West Coast USA driving habits. I would not get behind the wheel of a vehicle here, glad to let someone else handle it for me.

So, one might assume that Ragu is satisfied with his life, basically, as a chauffeur? Yes, and, here’s where some of the most important principles of Security Architecture comes into play.

  • Never assume what you don’t know: dig deeper, get the whole story
  • People matter; we are not replaceable objects
  • Effectiveness = Relationships
  • Trust is built
  • Authority is earned

I’ve been reminded about the importance of being an advocate for the success of people we meet. Let me tell you about Ragu.

Being a chauffeur is a rather new occupation for Ragu, a couple of months only. He has done many things:

  • A guitarist
  • A real estate finder
  • A builder

He’s faced down a local gangster group who threatened his family. Whew! But that’s not all.

Ragu was supervising the building of a home for someone else. In that area, he payed the women working for him a living wage, comparable to the men on the job. Then, some of the local villagers threatened his life for paying those women enough to survive. The villagers preferred the usual state of affairs where women are beneath men, kept in servitude, unable to make a living.

These villagers literally surrounded Ragu with big sticks, beating on his vehicle, threatening his life. Yikes!

So Ragu has seen some life, been through serious challenges. Perhaps a bit more than facing down a couple of enterprise Directors who don’t like one’s risk assessment, don’t you think?

OK. So why am I sharing this?

Because this is not the whole story.

Ragu is a product of the child labor market in India. His very poor family pulled him out of school at 9 years old. He was sent to a clothing factory to labor for 5 rupees each week, 1 rupee for a whole day’s work, at the tender age of 9 years old.

Still, the human spirit is indomitable.

Ragu is working on his bachelor’s degree. He continues to study the guitar. All this while driving a family around and raising his own children.

And, Ragu and I had a great conversation about getting started on a technical career. Ragu has aspirations. Because, it is impossible on a chauffeur’s salary to purchase a home in India.

I won’t go into my ideas about shifting into a technical career track.

What is important to me is that I’ve helped someone perhaps see his way to achieve his goals. And, what may not be obvious is that I’ve established a firm relationship which time and distance can’t destroy. Who knows? I may never see Ragu again. And that’s fine.

Still, through seeing the whole person, taking the time to understand, not the surface, but the whole story, I’ve established relationship. Rather than taking things at face view, I was curious, concerned, and one Ragu’s side for his aspirations.

I hope that I can say that Ragu and I are friends? And friends help each other.

Now please understand, I don’t think at this point that I need much from Ragu. His job demands that he drive me where I need to go, anyway. That’s not the point of this writing.

I’ve got a friend, a compatriot. I went out of my way to understand, to give what I have, little or great, to look through Ragu’s eyes. And I know in my heart that we can help each other, and that we will, if called upon.

And that value cannot be purchased. It has to be earned.

So it is in the practice of security architecture. My relationships are more than 50% of my practice. Trust is always earned. Relationships are built. I’m here at a conference on Enterprise Architecture put on by The Open Group. I’ve run in to one of my work compatriots, Srikanth Narasimin. We’ve walked together through some very difficult moments on projects. We have rather deep earned trust (I hope he would agree?).

So, we can at a very fast pace, figure out a problem (we just did on this on a troubled huge initiative on the job) There’s a lot of shared reference and resonance.

One achieves this kind effectiveness, I believe, by stressing the human side as much as technical depth and leadership. Srikanth and I can move fast because of our relationship, a relationship built up through projects, efforts, trust, listening to each other, seeing each’s point of view, understanding background information and how that influences that which is under discussion. Srikanth knows that I’m on his side, even if we disagree in this moment about a particular thing. Our larger resonance gives space for conflict resolution.

Again, you can’t purchase a relationship like this. A fancy title conferred by management won’t build this authority. These are built and earned.

I like to say that Security Architecture is at least one half people-centered. If you don’t like people, you won’t be happy as an architect. One has to be able to effectively interact with and influence:

  • Management
  • Other system architects
  • Implementors
  • Project Managers (“PM”) and others driving projects directly
  • Those charged with executing procedural operations and those charged with creating procedures and processes

I interact with these categories every day. If I specify something that cannot be done, it won’t get implemented. If I don’t understand the viewpoint and needs of each stakeholder, there’s no way that I can specify security requirements that will meet business need and which will be acceptable.

Interacting with Ragu reminded me that my effectiveness is directly related to my ability to form and sustain relationships. And relationships are built not by what I know, but what I hear and understand, my interest and concern.

As a practice, if I can, I make a practice of finding out about the personal life and concerns of the people with whom I work, as they choose to share. It’s a beginning place from which to start.

And, circling back to Ragu’s story, he told me, “I will never allow my children to be forced labor. They will get an education.” And so the world changes, yes?


/brook from Bangalore, India