As in many technical fields, system and network security is rife with best principles and practices. These are to help ensure that an acceptable degree of protection and access controls are in place, that employees practice "safe computing," and that ways to repair or recover from accidental or deliberate damage to systems and data exist. The problem, of course, is that only a minority of organizations chooses to pay more than lip service to such best practices and procedures.
Those who fail to toe the security line could face damage to or loss of critical assets, but many individuals and organizations fail to heed these dangers until they've been burned. Hindsight may indeed be 20-20, and there's nothing like a bad experience to gird one's loins to avoid a repeat. Nevertheless, I'd like to see you learn from others' mistakes instead of your own and tackle security properly before you get burned!
In a well-articulated and properly managed security environment, one critical document drives the definition, creation, and maintenance of how security is implemented and practiced. Such a document covers everything from personnel policies, to physical access controls, to the kinds of boundary safeguards erected between inside networks and systems and the outside world (usually, the Internet), to policies about how software may be purchased and installed on systems. This document is called a security policy, and it spells out what must be secured, how it is to be secured, what safeguards must be in place, and a whole raft of other terms and conditions that establish an organization's security posture.
Far too many organizations practice security without the guidance of such an over-arching document. This exposes them to potential vulnerabilities for a variety of reasons, since the lack of a security policy usually indicates that there's no single consistent, coherent statement of security practices and procedures available anywhere. As you'll soon see, enough work goes into formulating such a document that what is discovered and established along the way to the formulation of an initial security policy is often as important as the contents of the policy itself!
Defining "Security Policy"
SearchSecurity.com offers the following useful and cogent definition of a security policy:
"In business, a security policy is a document that states in writing how a company plans to protect the company's physical and information technology (IT) assets. A security policy is often considered to be a 'living document', meaning that the document is never finished, but is continuously updated as technology and employee requirements change. A company's security policy may include an acceptable use policy, a description of how the company plans to educate its employees about protecting the company's assets, an explanation of how security measurements will be carried out and enforced, and a procedure for evaluating the effectiveness of the security policy to ensure that necessary corrections will be made."
The key characteristics of this definition are worth exploring further, and might be stated as follows:
A security policy codifies all relevant security related information in one place, and thus creates a single coherent statement of an organization's security policies, practices, procedures, rules, and guidelines. Simply assembling this information can be valuable by itself, as much for what it leaves out as for what it includes.
Creating a security policy requires conducting an assessment and a valuation of an organization's physical and information technology assets. Here again, such a systematic inventory and valuation will help to establish what must be protected, and how much it is reasonable to spend to protect it. (It's fiscally imprudent to spend more on protecting an asset than that asset is worth; ideally, it should be somewhat less than its full value that's why people buy insurance.)
Creating a security policy also means formulating plans to protect an organization's assets. The plans must therefore address how attempts to foil or bypass security will be stopped as well as what kinds of back-ups, repairs, and recovery strategies can be applied should such attempts succeed despite best efforts to prevent them.
Because security threats and conditions change all the time, a security policy is never finished. It's called a "living document" because like the activities it describes and governs, a security policy (and its related security environment) must be constantly monitored, maintained, and updated to reflect current security conditions and asset valuations.
Security policies often include employee guidelines on acceptable use of systems, networks, and resources. Such policies not only address security and legal matters for example, forbidding download and installation of unauthorized software; enjoining users against software piracy; forbidding use of organizational assets or equipment to access inappropriate materials, and so forth they must also spell out clear consequences for failures to abide by such policies. Depending on the infractions involved, it's not uncommon for consequences to include reductions in pay, termination of employment, or criminal prosecution.
Employee education about security is a key ingredient in enforcing successful and usable security policies. Organizations should plan to spend time with employees (especially during new employee orientation) to make sure they understand security related personnel policies, what constitutes authorized and unauthorized behaviors, and how employees can properly practice security. The more valuable the assets that must be secured, the more important such training becomes, since human error, mistakes, or failures to follow security policies can have dire consequences.
It's important to spell out how security policies will be implemented and enforced at physical, technical, and human levels because this information translates into a blueprint for how security is practiced and enforced on a day-to-day level. This level of detail also provides the information necessary to train employees, set up workable physical access controls (smart cards, biometric scanners, guard-manned check-in/out stations, and the like), and configure software and systems to "let the good stuff in, and keep the bad stuff out."
Finally, because security is so much a matter of constant monitoring, maintenance, and upkeep, it's also important to spell out how the security policy itself will be maintained and checked (at least periodically). This should include routinely scheduled security scans, security audits, penetration testing, and so forth. In turn, this ensures that new vulnerabilities or exploits don't go unnoticed and that security practices coincide with how they are required to be practiced in the security policy itself. Consider this a necessary, valuable, and informative reality check in need of regular repetition.
By now, you should have a sense that formulating a complete and thorough security policy in keeping with the definition involves a tremendous amount of work. This is quite true, and a suggested sequence of events to implement such a policy appears next to help guide you through initial and ongoing aspects of this worthwhile endeavor.