I began my career in Information Security working for the Department of Defense, first for a Naval research facility, then Naval Intelligence, and finally with the National Security Agency. Information security for my first assignment meant locking your classified materials in a safe when you left the office at night, and making sure the office door was locked. Access to the building itself was restricted, complete with access badges and security guards. The guards would walk the halls at night and check the office doors to make sure they were locked. Sometimes they would enter the offices and check the safes to make sure they were locked.
Figure 1: Class 5 Security Cabinet One morning I arrived to find that I was written up for a security violation for failing to lock the safe the previous evening. I found out that even though I had put my materials away, shut the drawer, moved the handle to the “locked” position, flipped the magnetic “Open/Closed” sign, and spun the dial – I hadn’t locked the safe! Apparently I only spun the dial a half-turn or so where the procedure was to spin it full circle several times. Turns out that you need to do this to reset all of the cylinders within the lock which makes it work. I didn’t think this was a big deal because a) I was young and naïve and b) there were so many layers of protection to prevent the enemy from ever getting to the safe. My boss, however, was near apoplectic. He made it extremely clear to me that the rules were there for a reason and absolutely had to be followed. I learned some valuable life lessons that day, even though it took me years to figure it out. I learned the importance of following procedures, not taking shortcuts, and that security only works when all the pieces are in place. There were rules and procedures for every “layer” of physical security in the building, and every layer was tested and re-tested to make sure it was being followed to the letter. The best way to describe the whole experience was that there was a culture of security –every employee was disciplined, understood their role, what they should and shouldn’t do, they took their responsibilities seriously, they not only looked out for each other, but they also challenged one another, and they followed the rules. I spent much of my ten years (1986-1996) at the National Security Agency working on the defensive side, where the mission when I started was communications security (COMSEC) but by the time I left had evolved to become information security (INFOSEC). The main reason for the change in mission was to reflect that data was not just being sent in radio communications anymore but was now being sent by networked computers which were increasingly becoming attached to the Internet. The same principles, processes, and attention to detail that were applied to the physical security of data was being applied to the emerging discipline of computer, networking, and internet security.
Figure 2: The Rainbow Series What emerged was an exhaustive set of standards that detailed security best practices for every aspect of computer, network, and internet security you could imagine. The first document published was the “Department of Defense Trusted Computer System Evaluation Criteria” which came to be known as the “Orange Book”. Over the years, numerous supporting and related documents were published which became known as the “Rainbow Series”. The detailed analysis and recommendations put forth in this series of documents was unparalleled and in some ways ahead of its time. The series focuses on the use of computers and networks in a classified environment and is comparable to the more well-known series of Special Publications produced by the National Institute of Standards & Technology (NIST) for all unclassified federal information systems After spending nearly 13 years working for the Department of Defense, I ventured out into the private sector to consult and advise on matters of information security. On many occasions, after explaining some basic security concept to a customer and outlining what they need to do to be secure, I often heard the retort, “yeah, but we don’t need DoD level security.” Well, after twenty years in the private sector, and especially over the past 2-3 years with the proliferation of data breaches against major companies, I find myself wanting to reply, “yeah, you really DO need DoD level security!” What I have seen happen in private industry is companies are overwhelmed by the complexity of the problem of securing their business operations and too often skipping to the “solution”. There are hundreds if not thousands of tools and solutions on the market today that address one or more issues related to security, and the larger companies have invested millions in these solutions while smaller companies struggle to even provide basic security. I have had countless discussions with customers over the years focused on how to be as secure as their competitors rather than discussing how to be secure based on their own goals of security. The analogy of “you don’t have to outrun the bear, you have to outrun your friends” is used far too often. Major breaches keep happening, and too often we discover that the breach happened because some basic principle of computer security was not followed such as using weak or default passwords, relying on weak authentication, the lack of network segmentation, trust issues (especially of third parties), and successful phishing attacks. Pen testers also report that these weaknesses are the most common way they gain administrative access to their customers’ domains. The worst part of all this is that these are the same problems that were prevalent twenty-five years ago when this whole sense of Internet Security began…nothing has changed! I keep coming back to the thought “yeah, you really do need DoD level security”. I ask myself, “who has been doing data security the longest and knows the most about it?” and I keep coming back to the DoD. Maybe we need to take another look at DoD Level Security and consider how to apply it to the real world. What does this mean? Probably not what you are thinking. I’ve asked the question of many of my peers and colleagues and usually get a pretty quick “no” in response, and then we discuss the reasons why DoD level security cannot or does not work in the real world. It’s a good discussion, and one that I hope to continue within the community. This talk is intended to be the catalyst for discussion starting with an overview of the foundational nature of data security, highlighting the major tenets or goals of data security, introducing the risk equation, discussing how and why so many companies often fail at implementing the basics of data security, and exploring some ways that a DoD-centric approach to data security might be implemented in the private sector. Does new technology bring new challenges? Sure, and there are some new considerations for security that do not exactly fit into the date security paradigm, but the principles of data security often still apply. Brainstorming, discussion, dissension all welcome. Hint: This ain’t about Cyber! If you are interested in learning more, you can attend Jeff´s talk, Does DoD Level Security Work in the Real World?, at BSides Nashville on Saturday, April 22.
About the Author: Jeff Man is a respected Information Security expert, advisor, speaker, teacher, advocate, and curmudgeon. He has over 33 years of experience working in all aspects of computer, network, and information security, including risk management, vulnerability analysis, compliance assessment, forensic analysis and penetration testing. He has held security research, management and product development roles with NSA, the DoD and private-sector enterprises and was part of the first penetration testing "red team" at NSA. For the past twenty years, he has been a pen tester, security architect, consultant, Payment Card Industry (PCI) Qualified Security Assessor (QSA) and subject matter expert, providing consulting and advisory services to many of the nation's best known companies. Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
