Tuesday, June 20, 2006
Enterprise Architecture and Information Security
How come enterprise architecture teams simply don't get the notion of information protection?
Many folks know that I have been savage in not only creating a new role of chief security architect within my own enterprise but have talked with IT executives in other shops and have encouraged them to do the same. There are several problems that have emerged with this role.
Enterprise architecture and software development teams are used to solving technical problems and delivery a product or solution on time. The role of the chief security architect as currently implemented in most shops, usually enters the scene at the absolute last minute in loud mouth fashion declaring at least a dozen reasons why their solution is either insecure, won't work and is otherwise of insufficient quality.
This behavior has become everyday routine for most chief security architects. The savage practice of wrecking timetables which drives project managers to drink, suggesting actions as a quick-fix that cause performance to suffer and even more sinister the recommendation to remove functionality sorely demanded by the business community is busted at some level.
The role of chief security architect has been defined at a grass roots level and in reaction to many of the legal and regulatory challenges now costs enterprises millions in order to comply with. Before this role gets out of hand, I am firm in my belief that industry analysts should start not only defining wonderful grids of products in the security space but should also define job descriptions that can be handed to HR folks to ensure success. What would happen if say, James Governor of industry analyst firm Redmonk actually blogged out what he believes the role of Chief Security Architect should be within an enterprise? What if Dan Blum of the Burton Group also chimed in. Would us enterprisey folk start discovering value in industry analysis that we otherwise wouldn't have seen?
I wonder why neither of these two guys who have the right perspective on security never seem to hone in on the problem of security education within enterprises? I hope their thinking isn't just on products and vendors? The notion of secure coding practices almost never gets airtime. The only person that seems to care about this topic in the blogosphere is Gary McGraw who is CTO of Cigital but yet his approach hasn't yet reached the ears of many CIOs.
It isn't fair of me to say that Gary is the only one. Folks like Gunnar Peterson also frequently talk about this space but the rest of the blogosphere isn't providing amplification to what he writes. Maybe if all the readers of this blog who also blog could add him to their own blogroll, things would get better. Sometimes folks get it twisted by wanting a more lighter read and gravitate towards more mindless topics that folks such as Security Monkey covers. Ever noticed how he only talks about kindergartner topics such as virus, malware and other things that most large enterprises already have mastery of? It would be interesting to understand his perspective on secure coding practices, XACML, federated identity and other topics that are more meaningful going forward.
Several behaviors I have noticed include the disregard for building privacy in. Sure, many enterprises have established privacy policies but haven't even lifted a finger to actually incorporate the notion of privacy throughout their architecture. Large enterprises still think about security in terms of the DMZ where if it is on their servers, they can do whatever they want with the data.
Maybe the blame isn't 100% on the architecture team as some of it belongs in the legals folk court as well. Engineers should be aware of legal principles so that they can design products and services in ways that promote security, privacy and most importantly user control. When was the last time an enterprise architect last talked to the legal department on this problem space. I think we already know the answer...
How many architects are even thinking about building in the appropriate security functionality into their service oriented architectures? I am a big believer in the XACML specification which very few industry analysts seem to get. The ability to define policy within a markup language is powerful and ensures consistent support for execution. Imagine what would happen to enterprise security if portals such as Liferay, your Enterprise Service Bus and even relational database engines could at runtime consume policy from a single unified source?
XACML policy is a single, complex assertion for the authorization domain. Developers could also use XACML constraint functions as a generic language for writing assertions in any domain. We could even centralize the notion of data masking by having products from companies such as Cerebit consume them. We could within the enterprise even realize the same benefits that folks such as Kim Cameron talk about related consumer identity within our own enterprises. Tools such as Identity Engines and Securent can assist in this regard.
| | View blog reactionsMany folks know that I have been savage in not only creating a new role of chief security architect within my own enterprise but have talked with IT executives in other shops and have encouraged them to do the same. There are several problems that have emerged with this role.
Enterprise architecture and software development teams are used to solving technical problems and delivery a product or solution on time. The role of the chief security architect as currently implemented in most shops, usually enters the scene at the absolute last minute in loud mouth fashion declaring at least a dozen reasons why their solution is either insecure, won't work and is otherwise of insufficient quality.
This behavior has become everyday routine for most chief security architects. The savage practice of wrecking timetables which drives project managers to drink, suggesting actions as a quick-fix that cause performance to suffer and even more sinister the recommendation to remove functionality sorely demanded by the business community is busted at some level.
The role of chief security architect has been defined at a grass roots level and in reaction to many of the legal and regulatory challenges now costs enterprises millions in order to comply with. Before this role gets out of hand, I am firm in my belief that industry analysts should start not only defining wonderful grids of products in the security space but should also define job descriptions that can be handed to HR folks to ensure success. What would happen if say, James Governor of industry analyst firm Redmonk actually blogged out what he believes the role of Chief Security Architect should be within an enterprise? What if Dan Blum of the Burton Group also chimed in. Would us enterprisey folk start discovering value in industry analysis that we otherwise wouldn't have seen?
I wonder why neither of these two guys who have the right perspective on security never seem to hone in on the problem of security education within enterprises? I hope their thinking isn't just on products and vendors? The notion of secure coding practices almost never gets airtime. The only person that seems to care about this topic in the blogosphere is Gary McGraw who is CTO of Cigital but yet his approach hasn't yet reached the ears of many CIOs.
It isn't fair of me to say that Gary is the only one. Folks like Gunnar Peterson also frequently talk about this space but the rest of the blogosphere isn't providing amplification to what he writes. Maybe if all the readers of this blog who also blog could add him to their own blogroll, things would get better. Sometimes folks get it twisted by wanting a more lighter read and gravitate towards more mindless topics that folks such as Security Monkey covers. Ever noticed how he only talks about kindergartner topics such as virus, malware and other things that most large enterprises already have mastery of? It would be interesting to understand his perspective on secure coding practices, XACML, federated identity and other topics that are more meaningful going forward.
Several behaviors I have noticed include the disregard for building privacy in. Sure, many enterprises have established privacy policies but haven't even lifted a finger to actually incorporate the notion of privacy throughout their architecture. Large enterprises still think about security in terms of the DMZ where if it is on their servers, they can do whatever they want with the data.
Maybe the blame isn't 100% on the architecture team as some of it belongs in the legals folk court as well. Engineers should be aware of legal principles so that they can design products and services in ways that promote security, privacy and most importantly user control. When was the last time an enterprise architect last talked to the legal department on this problem space. I think we already know the answer...
How many architects are even thinking about building in the appropriate security functionality into their service oriented architectures? I am a big believer in the XACML specification which very few industry analysts seem to get. The ability to define policy within a markup language is powerful and ensures consistent support for execution. Imagine what would happen to enterprise security if portals such as Liferay, your Enterprise Service Bus and even relational database engines could at runtime consume policy from a single unified source?
XACML policy is a single, complex assertion for the authorization domain. Developers could also use XACML constraint functions as a generic language for writing assertions in any domain. We could even centralize the notion of data masking by having products from companies such as Cerebit consume them. We could within the enterprise even realize the same benefits that folks such as Kim Cameron talk about related consumer identity within our own enterprises. Tools such as Identity Engines and Securent can assist in this regard.
