Monthly Archives: September 2008

Architect Surprise!

Posted on by

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.

cheers

/brook

What’s Occurred in Web Years?

Posted on by

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.

cheers,

/brook

(from the Denver airport)

Web Years

Posted on by

“Web Years”

I’ve been using this term lately to describe ever increasing pace of change. I started using the term as a jest, “dog years” are faster than human years. “web years” are acceleratingly shorter.

I arrogantly imagined that I’d coined the term. Not a chance, 1996.

I blog about this to introduce the term in the context of an accelerating pace of change that is fundamental to thoughts I’ve been having about Web 2.0 changes.

I want to emphasize web years in order for me to explain my thoughts about Web 2.0/Social Computing/Communication Convergence.

If web years are getting faster, then the time we have to react is getting shorter. Worse, how do we get in front of trends?

A lot of folks that I’ve been talking to about security issues of Web 2.0 are discussing the “future”.

But Web 2.0 happened (note the past tense) in web years. The original DARPANET mesh built out over a period of years. Web 1.0 in at most, a few years (I experienced the change happening in just about a year).

Social computing happened in a few months! (of course, some of the underlying tools have been around a lot longer)

Yep, accelerating.

And the change has already happened. It’s done. Organizations are catching up with plans. Some security folks are still worrying about the perfect network perimeter. LOL!

That doesn’t mean that I think organizations have implemented Web 2.0. Please don’t mistake me. I simply believe that the way people use the web has already changed. The tools are there. We’re grappling with how to make use of these changes and how to secure them.

The perimeter is gone, gone, gone. That is not to say that we should throw away our network controls. These are a part of our security toolkit, absolutely. But information security has not equaled network security for years.

I will be blogging about changes with which I think we security folk have to catch up in another edition.

take care,

/brook