If there is one thing good that the COVID-19 pandemic did to Corporate America was to sound the alarm bells for the CISO to have a good Security Policy in place, which will serve as the benchmark of what to do when another disaster strikes. This was an often-ignored document, but now they are starting to realize the sheer importance of having one.
There is no one size fits all kind of policy, rather, you have to create one that is unique to your own security requirements and needs. In this article, we examine some of the key areas that your newly crafted Security Policy (or even upgraded one) should have.
What They Are
Here is what you should consider having in it:
- Software application security:
Probably the biggest issue here is implementing clear guidelines about source code creation. It’s one thing to develop it in time for your customer or internal needs, but then it is another to actually test it along the way to make sure that it is secure. This simply means that any vulnerabilities or holes that are found in the code must be remediated quickly. Unfortunately, many software development teams wait until the very end to do this, up until to the point the project is supposed to go into the production environment. Doing it this way will not only delay things further, but checking for holes will be done in a haphazard fashion. Therefore, your Security Policy should mandate the testing of this source code in a phased in approach, or after each software module has been completed. This will ensure that any gaps found will not only be corrected, but that it will not cause a cascading security effect for the other modules as they are completed. Equally important here is the testing of API libraries, especially those that are open sourced. Very often, they go untested for long periods of time, and have not been patched with the latest software upgrades. Your development team has to make sure that both of these tasks are done, and in time.
- Determining Cyber Risk:
This is one of the biggest buzzwords in the industry today, but there really is no widely accepted definition of what Cyber Risk truly is. In very broad terms, it can be thought of as the level of tolerance you and your company can endure before your business takes a major hit, both in terms of the bottom line and brand reputation. Therefore, it is absolutely crucial that you include in your Security Policy what your definition of Cyber Risk is (per your environment), and how you plan to measure it. One way to do this is to take an inventory of all of your digital and physical assets, and rank them according to vulnerability based upon some kind of categorization scale (such as 1 – 10, where 10 would most vulnerable and 1 would be least vulnerable). Obviously, you would either want to deploy new controls or revamp any existing ones on those assets that have been ranked 7 or higher. Once you have done this, then these controls need to be tested once again to make sure that they are providing an optimal level of protection. Doing this is not only important for your Security Policy, but it will also make you come into compliance with the data privacy laws such as that of the GDPR, CCPA, HIPAA, etc., and avoiding any audits and very stiff penalties.
- The inclusion of Disaster Recovery and Business Continuity:
Very often, there is a certain level of confusion between the two, in that they mean the same thing. But the two are very different. Disaster Recovery (DR) is primarily concerned with how you are going to restore critical business processes after you have been hit (the short-term perspective) and Business Continuity (BC) deals with how your business is going to cope in the future (the long-term perspective). While these are two separate documents, they ae considered to be a central part of your Security Policy, and they should be treated as such. With regards to this, you need to spell clearly how often you plan to rehearse your plans, and how you will keep your respective documentation updated from the lessons learned.
- Cloud Deployments:
With the 99% Remote Workforce now a reality and will be so for a long time to come, your Security Policy needs to spell out how you plan to safeguard your information and data that you store in your Cloud environment, especially when it comes to the PII datasets of both your employees and customers. Data leakage has always been a continuing problem here, whether is it is intentional or not. In this regard, your Security Policy needs to address how you will manage your Identity and Access Management (IAM) platform. This means how you plan to organize your groups and profiles (assuming you are using Azure Active Directory), and the rights, permissions, and privileges that each end user or third party will have. One of the provisions that your Security Policy should contain here is that of Least Privilege, which is giving the stakeholders in your company just enough to access what they absolutely need. If you are planning to implement the Zero Trust Framework, then the approach as to how plan to implement needs to be detailed as well in your Security Plan. Most importantly, you also need to map out timeframes when it comes to auditing all of the permissions that your employees have, so that they do not have any more than what is needed. Typically, this should be done at least once a quarter.
- Keeping up the Cyber Hygiene:
This all comes to the type and kind of Security Awareness training programs that you give to your employees. You do not have to go into all of the details of this in your Security Policy, but you need to include the frequency as to how plan to deliver them, and how you plan to test your employees to make sure that they are practicing in the real world what they have supposedly learned. From this perspective, it is highly recommended that you deliver this at least once every two months or so.
While these components detailed in this article can be considered to be amongst the most important for a Security Policy, there are other areas as well which are also important. These will be reviewed in a future article.