MAP BUSINESS AND TECHNOLOGY PATHS
This might sound like a no-brainer, but it's a bit more complicated when you dig into it. We've learned to think of technology as complex mechanisms and sophisticated software. However, if you talk to an archeologist, the stone axe is also an example of technology. Ancient technology, yes, but technology nonetheless.
I think this opinion of what "technology" is, is the reason that we ignore a major type of technology that glues our present solutions together: people. When an organization engages in process reengineering, the first thing that they do is look at the relationship of people and how efficiently they exchange information in the quest to accomplish their mission. They ask how well they use the tools that have been afforded them and how many workarounds are in place to "fix" poorly engineered processes. All too often, we're given new technology, but instead of reexamining how we can put this new technology to good use, we just use it to take the place of an older process without understanding how it can make the overall process better.
To counter this, we must examine our business processes with respect to security so that we can understand where the human paths are with respect to the technology paths. We must also be willing to push for change where needed. Our technology paths, both human and technological, need to be understood if we're going to create a closed-loop process.
We need to be able to identify them and measure them to understand how much of an impact any delay is going to have on our security process. For example, your organization might have an automated patch management system that pushes patches and updates out to thousands of endpoints in a few minutes. Because of this technology, you can stand up in front of the board of directors and tell them that your solution pushes updates to vulnerabilities in minutes! The problem is that in many organizations there's a manual process of evaluating the patch, called regression testing, that can take as long as three months!
This means that we, as security people, need to understand our company's business processes and instead of saying "no," we need to find ways to say "yes" that encourage the business plan to grow and adapt to the changing business objectives. When new technologies appear, we need to understand how those technologies will impact our security and our ability to compete effectively in the marketplace. How many organizations, because the security group is afraid of it, haven't deployed wireless technology regardless of its demonstrated ability to simplify deployment and reduce associated costs?
Who do you think is going to win in the marketplace when the market gets tough and margins get small? The organization afraid to use technology because their security process can't handle it, or the agile group that understands, security and business processes can work together?
CAN WE BUILD A BETTER MODEL?
I believe the answer to this question is a resounding yes. I think that most of what we need is already here; we just need to connect it a little better than we have in the past.
I know that I can have a mechanic go over the car with a fine-tooth comb, but that won't eliminate the possibility of a flat tire or an exploding engine later on. I've reduced my risk by examining the car prior to buying it, but I still run the risk that something could happen later.
What I have done by taking the effort to examine the car is begin the process of engendering trust. By setting a minimum level of capability, I have enabled myself to trust the system—in this case,my car—to behave in a manner acceptable to me. I believe that this is also possible on our networks. By setting a minimum level of capability, we can set a minimum level of trust in the systems that join our network.
Learn more about the old way of thinking that has controlled network designs and management techniques for too long. Download the rest of Chapter 3: Something is Missing (.pdf)
Note: Printed with permission from Addison-Wesley. "Endpoint Security" by Mark S. Kadrich. Copyright 2007. For more information about this title and other similar books, please visit www.awprofessional.com.
This was first published in May 2007
This was first published in May 2007