Security Architecture and the Zachman Framework E039 2024 10 14
A Bit of Security for October 14, 2024
Today we’re looking at information security architecture. I’m holding two pieces of glass, which I picked up from the pavement outside the John Hancock Tower in Boston in 1974. The company built the tower as its new headquarters, and it was magnificent – 790 feet, sixty stories tall, with a solid glass exterior. It wasn’t planned that way – originally the building was supposed to be covered with 11,000 planes of dual-laminated glass, 11’ by 6’ or so. But an engineering flaw in the design meant that the panes flexed too much, so if there was a wind, the pane would break into these safety-glass crumbles. To fix the problem the panes had to be replaced with solid glass panels, and to bear the extra weight, one of the elevator shafts had to be filled with reinforced concrete.
The architect, I. M. Pei, was brilliant and inspired – the building was striking. It would seem to vanish under certain lighting, so you would only see the sky and clouds. But the architecture wasn’t properly validated for security, so the original design had to be comprehensively and expensively retrofitted.
Constructing a building is like making software. You start with a plan, a sketch; then you fill in the details. The sketch isn’t the blueprint, and it isn’t the building. Stepwise refinement (in software engineering terms) is like taking the sketch into a blueprint then developing the detailed plans for plumbing, HVAC, wiring, framing, etc. Digging and pouring the foundation is like preparing the environment in which the software will run. We don’t certify software engineers, but me should. There is a common set of knowledge that any software engineer should possess if they are to design complex applications. Failing that, costs will run out of control, products will disappoint, and users will be turned off.
John Zachman formalized this notion in the Zachman Framework (). Where is information security? It’s akin to the building inspector. Along with the functional requirements – what the program is supposed to do, what the business process it is supposed to embody, there are non-functional requirements. You have to be able to understand what resources the software uses. Where is the performance bottleneck? When it fails, what went wrong? All of the systems management disciplines require some thought. Analogously, how will be building stand up to wind? Are there enough doors? Is the fire suppression system adequate?
If you don’t have an enterprise architecture defined, you probably have a messy, sloppy architecture – meaning you won’t be able to enhance the product, extend it for new environments, fix it when it breaks, or add new capabilities when business needs change. And if you don’t have a security architecture, you will add to your company’s collection of fifty or sixty products from some of the over 4,000 information security companies in dozens of segments working today.
Most important, if you don’t have an architecture, you’ll be making tactical decisions that have long term strategic implications. You will waste money and resources. Let’s not do that.
Security Architecture and the Zachman Framework
A Bit of Security for October 14, 2024
An information security architecture avoids many problems and helps fix the ones that get by. Listen to this -
Let me know what you think in the comments below or at wjmalik@noc.social
#cybersecuritytips #architecture #zachman #softwareengineering #certification #BitofSec