Secure the Heritage
Good post by Scott Stender on using the SDL on legacy code (ht Andy), it is always refreshing to see security pros talk about real world tradeoffs. I would also add the following:
1. What most people call "legacy" systems should be called "heritage" systems. Legacy has a negative connotation. Most places I go, the "legacy" is the reason why people get paid and what actually runs the business. I think its more respectful to call them heritage systems a la Krafzig, Banke, and Slama.
2. Most heritage systems have almost no security mechanisms whatsoever. They were designed for benign environments. Most mainframes have no encryption. You talk to a mainframe over MQ Series, yet MQ Series literally has no access control. This is the transactional backbone of 499 of the fortune 500 we are talking about. You still with me? Good. So writing security requirements is important, but you are not going to have anywhere near the security architecture capabilities that you are used to.
3. So one *big* thing to consider with heritage is - don't connect your heritage to hostile environments at all, use an ESB to connect indirectly and/or replicate out to data caches. So the heritage publishes data and subscribes to data, but is not in any way connected to a world it was never designed to deal with. Of course this doesn't always work either, but it is something to consider. The starting point should not be - "how do I connect the heritage to the web?" the starting point should be "how do I share resources and functionality on my heritage with the web", again, often you do have to connect but sometimes not.
Whenever I read something from iSec it is generally thought provoking because they have worked on a lot of interesting stuff. How do we get these folks to blog more?
Comments