Complete security audits should be performed at least once a year, with quarterly audits highly recommended – especially if you have a legal obligation to conform to certain security standards such as HIPAA, Sarbanes-Oxley, FERPA, or PCI DSS etc.
Quarterly audits are recommended because organizations tend to keep changing all the time – such as changing network configurations, adding / removing employees, or opening a new branch etc. All of these events have the potential to introduce a new security threat vector, and thus need to be addressed accordingly in order to comply with your legal obligations.
Running security audits on a regular basis also helps prevent us from having to come back every week to fix the same issues for you over and over again. While the repeat business is nice for us, such repetition is surely more trouble than it is worth.
Phase 1: Establishing the Rules of Engagement
This phase involves determining the scope of the project – such as prioritizing the protection requirements for individual business areas and processes based on operational impact.
Continuing efforts will be to secure each system / process as defined in this scope. Adding more physical locations or business processes will change the scope, and will need to be defined separately.
The minimum information we need to run a security audit include:
- The appropriate day and time (or time range) to run our scans
- The IP Address or IP Address Range to scan
Additional information which is very helpful for running a security audit includes:
- Description of the organization
- Description of the business functions / information to be secured
- Geographic location(s) of the infrastructure
- Physical layout of the IT infrastructure in each location
- Logical network diagram of each location and as a unified system
- Complete description of the organization’s security policy*
- List of information systems to be included
- List of information assets and their owners
- Classification of information assets i.e. value, sensitivity, and replaceability of each asset
- Firewall / network configuration rules
- We can find out all the information listed above using only the IP address. It just takes longer to complete the audit.
- If some processes or business areas are to be excluded, it needs to be determined whether they are actually separable from the rest of the system to be audited.
* Your organization’s security policy is very important for determining the scope of the project. The stipulations dictated by this policy will help us understand exactly what is needed and required to properly secure your organization – for example some of the questions we need answered include:
- Why is this information strategically important for your organization?
- What are the business / legal requirements that govern your information security policy?
- What are your organization’s contractual obligations towards providing security for information collected by the organization?
- What steps does your organization take to ensure information security?
- What is the current organizational structure of those people responsible for defining security policy and enforcing security protocols / procedures?
Phase 2: Reconnaissance
From this point our goal is to begin analyzing each business area / process for security vulnerabilities. There are a number of scans and analyses we can perform depending on the scope defined in phase 1.
Human Threat Analysis
This is where we expose each asset to numerous human-based threats. We do not provide recommendations for natural or environmental threats such as earthquakes, power failure, chemical spills, pollution etc.
Human-based threats are (unsurprisingly) those enabled or caused by human beings. Such threats range from the unintentional (such as incorrect data entry) to the deliberate and outright vengeful – for example gaining unauthorized access to sensitive information, uploading malicious software, or intentionally corrupting data storage systems.
This type of analysis typically involves:
- Making a comprehensive list of all threats which are likely to occur
- Interviewing key people
- Researching past records of incidents within the organization
- Using precedence i.e. the past records and experiences of organizations in a similar geographical area and / or subjected to a similar working environment
Vulnerability is a weakness in the design of a system, which could be exploited by some threat. The purpose of this analysis is to uncover such vulnerabilities before that can be exploited – and there are several methods for accomplishing this:
- Historical Incident Log Review – when available these provide a good indication of where vulnerabilities occur within a system.
- Design Documentation Review – we often find information security treated as an afterthought when the original design specifications were first drafted. The older the specifications in question, the truer this issue will generally become.
- Tools-based Security Testing – where we essentially use the same tools that a hacker would use to try and break into your system. We do this in order to test the strength of your security – since doing so dramatically reduces the number of easy vulnerabilities that even amateur hackers could exploit.
- Using Risk Analysis Tools – we use a number of commercial risk analysis tools in order to evaluate the security level of each system / process.
After performing all our various analyses and scans, we can then produce a report that illustrates what vulnerabilities exist, where they exist, and how they can be maliciously exploited or inadvertently triggered.
Phase 3: Review & Diagnosis
At this point we will review the results of all our testing and analysis – we are able to generate a report, and come up with a list of recommendations to solve or at least mitigate the risks presented by uncovered issues.
The report that we provide you will only tell you part of the story, because what is described in this report will only really make sense to IT people in technical terms – rather than practical business terms. For example it may say X and Y are missing / not implemented – but will not describe WHY these points are so important or how big a security risk these represent.
It is therefore highly important that we have a discussion about this report – at least a phone call, or preferably a meeting) about. So key decision makers in your organization can fully understand where the organization is being exposed to risk.
Actions may require modifying your security policies, implementing various solutions to reduce risk, and / or purchasing new security products to reduce risk areas. From your end you will need to weigh the costs vs. benefits of acting upon these recommendations.
Phase 4: Implementation
Based on agreements from the previous phase, we will now begin to implement various solutions to remove or reduce certain security risks.
Here is a list of some of the actions we could perform based on our diagnosis. Depending on your exact needs this could involve one, a few, or several of the points listed here:
Natural and Environmental Threats
- Disaster Recovery Plan
- Backup and Recovery Plan
- Network Recovery Plan
- Password Security & Controls
- Internet and Mobile Access Security
- Enforcement Procedures
- Email Security
- Program Change Controls
- Version Controls
- Application Software Security
- Databases Security
- Network & Telecommunications Security
- Operating Systems Security
- Firewall Security
- Incident Response & Management
- Server & Hardware Security
- Virus / Malware Protection
- E-Commerce Security
- Data Encryption
- Administrative Controls
- Third Party Application / Service Security
- Teleworking Security
- Cloud Security
- Virtualization Security