Policy is Everywhere
Think of every company you have ever worked for. Whether it was a job in a warehouse, or employment in an office, there was always a policy to follow. In fact, when you think back to your earliest days, your family also had policies. Policies are the rules established to keep order within a group. Sometimes, policies are not followed, or are simply ignored.
According to a report issued by the Federal Aviation Administration, one of the primary causes of policy failure is a lack of available, current, or well written documentation. That was followed by the difficulty of the task being performed; and concluded with work environments leading to failures to follow procedures. Sometimes, the failure is the result of the staff not understanding why a policy exists.
When we think of aviation failures, we would assume that everyone would follow policies, as failure to do so could result in deaths, but as seen from the aviation report, even in a critically important environment, policies are not always followed.
The problem of ignored or evaded policy is not limited to the aviation industry. Although the consequences are not as dire as a failed airplane part, failures in policy can have damaging effects in any industry. Damages can range from monetary penalties, to loss of consumer confidence.
The software industry is not excluded from the industries where policies are vital to success. In fact, a software failure was partially responsible for the infamous MAX 737 airline disasters.
Where The Breaches Are
When we think about recent breaches, many of them are the result of systemic failures in security. Were these the result of an absent or ignored policy? It is unimaginable that any company in the last ten years would not have a security policy. In many cases, company policies regarding cybersecurity are the result of regulatory directives. Where is the disconnect? Could it simply be one of nomenclature?
One way to avoid harm that can result from failed policies is hiring a qualified person who knows the differences in the language of policies, standards, procedures and baselines, and how they fit into the overall activity of the organization. In the area of software manufacturing, a person who has attained the Certified Software Security Lifecycle Professional (CSSLP) designation is uniquely qualified to oversee the development of policies to best protect a company.
The Language and Structure of Success
A successful organization follows a business plan to achieve its goals, with the ultimate objective of becoming prosperous. In order to realize a mission, most organizations have operational, tactical, and strategic visions. An extreme example of these can be seen in military parlance. Fortunately, most corporations do not need to operate at the granular level of a conqueror. However, the concepts of operations, tactics, and strategy help to set the direction for a company. The CSSLP Common Body of Knowledge (CBK) is an excellent source for the clarifications of each of these and their appropriate usage. To use the example of a ship at sea:
- An operational policy is used for short-term goals. These policies are directed at day-to-day activities. Think of these as setting up the crew and the costs for a voyage.
- A tactical policy addresses medium-term aims. Tactical policies usually involve a project that needs to be completed. Think of tactical policy as plotting the stops on the way to the destination for refuelling.
- Strategic policies are the “big picture” intentions of an organization. As such, they are written at a high level. Think of those as keeping the ship on course.
The CBK also beautifully explains the distinctions between standards, baselines, procedures, and guidelines. The language of these is very specialized, and various tell-tale signs make it easy to recognize their distinctions. These are the documents that support the policies set out by the organization.
- A standard is often descriptive of a particular product or style of implementation. A command to use a specific operating system, or a specific coding language would be included in the language of a standard. Standards are mandatory directives.
- A baseline will describe things in the manner of a “minimum”, or a threshold. Baselines are also mandatory directives.
- A procedure will contain step-by-step instructions about how to proceed to accomplish a particular task. Procedures are also mandatory.
- A guideline can be thought of as an advisory document. Unlike all the other position documents, a guideline contains suggested methods for creating standards and procedures. A guideline would not contain mandatory directions.
Keeping It All Together
It is easy to see that many lines can be blurred when the preceding terms are misunderstood. To get back to our aviation example, a mechanic seeking the correct setting for an auto-pilot control will not be served well if his document speaks about the overall direction of the airline company. Similarly, a software developer seeking to understand the versioning rules of the company will not benefit from a document that lists the target operating systems of the software. That is why it is important to utilize the skills of a trained professional to keep it all in order.
Order, however, is not the only requirement. A good policy is one that can be understood by all who must adhere to it. This requires insight, and more importantly, collaboration across all the departments who will be impacted by the policy. This is one of those “soft skills” that are too often overlooked. When it comes to writing policies, perhaps the most important soft skill is the humility to accept constructive criticism and an open mind to accept change. Listen to the concerns of those who have to live by the policies.
A Constant Project
Policies are not carved in stone. They must be capable of change, and they must be updated regularly. (Usually, there is a policy that establishes the baseline time-period for policy review.) In a software company, changes are almost constant, and failure to update the relevant documents can have far-reaching negative effects. Moreover, part of a good cybersecurity program prescribes policy review, and the auditors will be sure to examine those as well.
The Right Person For The Job
The software development lifecycle (SDLC) is not only a process for successful software implementations; it is also memorialized in documentation to add direction and cohesion. Part of the documentation must include security, which is a dynamic and fluid environment, requiring trained individuals who understand the threats and vulnerabilities that may jeopardize successful software implementations. A person who holds the CSSLP credential understands all aspects of software security. Topics such as software security policy, secure software design, testing, and secure implementation are all part of the essential knowledge to achieve the CSSLP designation.
To learn more about the importance of a good software security policy, read our white paper, The Confessions of a Software Developer.
How the CSSLP Can Help You Succeed
The distinctions between the different types of policies are not to be taken lightly. A misdirected policy can result in an ignored policy. An employer needs to be certain that the person they hire can distinguish these subtleties. A sure way to do that is to look for someone who has proven, tested skills. The CSSLP credential offered by (ISC)² is the perfect way to show that you possess the required understanding and skills for this important facet of information security.