Information Security Program

Information Security Policy Development

Firstly, you must understand what regulations and requirements your organizations may be governed by? For example Health Care is governed by HIPAA, the financial industry is regulated by PCI DSS. Once you have an understand of your organizations regulatory requirements you also need to take into account your company’s unique operating environment and understand on how it should be governed.

From here you are ready to start your skeleton policy set, now you must identify what Cyber Security Framework your organization is aligned too and decide if you are going to map to that framework, or if it differs map your policy set to the regulatory requirement your organization is likely to be audited against?

There is no right or wrong answer, in the event of an audit the auditor may require you to map your policy set to the specific regulatory requirements. As an example an organization may decide to align its Cyber Security Practices and operations to a NIST or HITRUST framework but for ease of auditing their policy set may be directly mapped to HIPAA.

Now you will follow the controls outlined in the framework you have selected and build out the skeleton policy set or use the one I provide in the community subscription package. This will ensure that you are meeting the control requirements defined by the framework you are aligning too. In most cases you will have several policies that are separate from this core set to meet your needs. This would include things like a Remote Access Policy, a Sanctions Policy or an Acceptable Use Policy in which you may want new hires or those that it effects ie. remote workers sign the policy acknowledging their understanding.

With the skeleton policy template in place now you can work through the categories and fill in the blanks outlining your “Though shall not” statements defining the security requirements for that control category.

*Note: Once a policy is implemented it does not mean the outlined requirements have to be in place today, but you do need to have a plan of action for bringing your organization into alignment with the policies which have been approved by the Senior Leadership.

IT Security Standard Operating Procedure’s

Now its time to drive those requirements defined within your policy set into action across your organization. That is where creating security standard operation procedures comes into place. In most cases this will lead to developing unique security SOP’s for the varying business units, branches, departments across your organization. Developing security driven standard operating procedures at the department level allows you to account for that departments specific needs and use cases, and I know that sounds like an unsurmountable task but lets break it down.

At the start of this project I often like to work with my clients to develop something I call a Roles by Controls Matrix, just select the hyperlink for a free download. In this you will again map back to the framework your organization is aligning too and account for any special requirements your business may have. List out the controls utilized across the organization as well as identify all of the key departments. At that point you just fill in the blanks identifying the security control and what departments have a hand in managing that control and to what level. This will give you a plan of action for which departments you want to tackle first and how many departments you are going to need to work with.

Developing departmental security standard operating procedures can take several trial and errors and hours of your precious time as you work out the kinks from your initial attempts. To help guide you in this process I have developed a template that will allow you to quickly move into taking action and driving security practices across your most critical business units. Run into a problem I am only a phone call away.

Enterprise IT Standard Configuration Guidelines

Your organizations standard configuration guidelines are a core element to ensure governance and standardization over your IT infrastructure. As new assets are introduced into the IT environment they need to be brought to the organizations standard. This is one method used to manage the risk posture for the organization. Even though most organizations have a general sense of the standards they keep, there is often one gate keeper who decides the hardening standards making the intake for new solutions a bogged down complicated effort.

A key aspect of documenting the IT standard configuration guidelines is ensuring that the organizations data and associated IT infrastructure maintain a strong security posture throughout the lifecycle of the assets.

Secure configuration must be addressed throughout an information asset’s lifecycle. This includes:

• Inception – Addressing secure configuration at the beginning of the lifecycle ensures a secure product and reduces the costs involved with retroactively implementing Information Security functionality. Developers and stake holders should use this standard to determine Information Security related requirements on new projects. The <CLIENT> IT Security team must review the security design to ensure compliance with this standard prior to
• Development – Secure configuration guidelines that are built into the requirements for a new product are used to ensure security functionality is implemented as appropriate in each aspect of development. Before go-live the Secure Configuration of the new product must be reviewed to ensure the planned and accepted security requirements have been successfully implemented. Security must be tested to ensure it is in place before a new or updated system is allowed to go into production use (this is best served using the automated vulnerability scanning tool).
• Production – Development staff should not have administrator access to production resources. Systems must be monitored to ensure they are not being modified and are performing as
• Maintenance – Secure configuration must be periodically tested and/or vulnerability scanned to ensure new issues and vulnerabilities do not exist on the system. All updates and patches must be applied. Changes to an asset could introduce vulnerabilities and issues to a once secure system. Post modification testing and/ or vulnerability scanning are
• Retirement – Secure configuration must be addressed on any system where archiving is taking place in preparation for retirement. Backup and BCP processes must also be addressed to ensure recoverability of data if required.

There are 5 layers covered in your organizations IT Standard Configuration Guidelines:

• Application Layer
• Network Layer
• Database Layer
• Desktop Layer
• Server Layer

Get Our Newsletter