The top 7 things organizations are not doing, but should be. 

By Jason Broz

A current state review of an organization’s security program and risk posture at a specific point in time is known as a point-in-time assessment. Point-in-time assessments are a standard practice for many organizations. This practice leads to a two-month “fire drill” in preparation for the assessment, ensuring systems are hardened, documentation is reviewed and updated, and testing and analysis is performed in an effort to ensure compliance requirements are met. 

The Payment Card Industry Security Standards Council (PCI SSC) has recognized this as an issue and has taken steps to focus attention on incorporating security as a Business as Usual (BAU) approach in Version 3.0 of the Payment Card Industry Data Security Standard (PCI DSS) framework.

There is a dire need for strategic focus within the IT Security industry. Many organizations partake in a continual implementation of tactical fixes that do nothing to mature the organization’s IT security program. Penetration tests often discover weak passwords in use. While employees can be required to change passwords, the larger issue requiring minimum complexity and training on the dangers of using weak passwords are not effectively addressed. Point-in-time assessments provide a limited view of day to day operations. 

  1. Testing Incident Response and Continuity Plans
    Performing “live” tests of incident response and continuity plans under duress of an actual incident leaves little time to identify flaws in the plan. After action reviews often focus on the prevention of the specific incident, and not addressing potential issues with the plan itself. Both the specific incident and flaws within the plan should be addressed during the after action review process.
    Not performing tests of continuity plans also leads to communication breakdowns. New or existing employees are not made aware of their responsibilities. If employees are not aware of their role in continuity plans or incident response, the plan cannot be effective, and when a real incident occurs, the organization will suffer longer downtimes and likely lose more data as a result. 
  2. Security Awareness Training
    Security Awareness Training takes many forms. This is highly dependent on resources. Many individuals tasked with performing this training lack sufficient knowledge, time, or drive to meaningfully implement. Users often see training as another task to complete, one that doesn’t provide any real value. Typically, this is an annual process with very little reinforcement or attempts to engage users (e.g., emails, posters) throughout the year. Individuals are required to sign an attestation of understanding, but it doesn’t mean that it is understood.
  3. Continual Risk Analysis
    Many frameworks require at least a periodic formal risk assessment, but many companies do not incorporate this assessment into an overall Risk Management Program. 
    If risk is not taken into consideration early in the process when developing new systems or business processes, after changes, or continually as a part of the BAU approach, there is greater potential that vulnerabilities will not be addressed. Organizations should use an industry standard framework such as iRisk, FAIR, OCTAVE or NIST.
  4. Vendor Management
    Many times service providers only hear from their clients when proof of compliance is required. Having an established, proactive relationship between vendors and clients will be mutually beneficial. Clients will see faster resolution of issues and vendors will be able to close holes in systems, leading to more mature programs and improved risk postures. Responsibilities are often not clearly defined and acknowledged by both parties. These should be spelled out in the contract and validated by site visits or other means. 
    Watch our webinar: Solving the Vendor Risk Puzzle
  5. Secure Development Practices
    The development and modification of systems that handle sensitive data is a regular practice and should be continually monitored. With the speed of technology, integration of systems and an ever-changing threat environment, it is critical that developers are trained regularly. Academia teaches programming techniques, but not secure coding practices. 
  6. Logging Review
    Logging itself is not a detective control. Review of logs is the control. Manual log review is tedious. The alternative is automation with thresholds being set to alert on anomalies. Alerts need to be configured properly. Improper configuration will lead to being inundated with alerts and ultimately desensitization. The contrary will lead to missing actual events. Or, you can implement persistent threat modeling, with an incident response program. 
  7. Access controls
    Improper access to sensitive data is a breach waiting to happen. Change is an inevitability in any organization. If all accounts are not regularly audited, there is potential for an individual to gain access to data for which they have no business need. Departmental changes and operational realignments may leave role permissions askew and should also be reviewed.

A Signed Report on Compliance, Does not a Security Program Make
Many organizations can reach compliance when they need to do so, but if they fail to address one or more of the above areas or any of area of the 12 PCI requirements, they risk not being in compliance and the potential for a data breach is increased immensely. Compliance verifies nothing more than minimum security baselines for protecting data, and it should not be viewed as the ‘gold standard’. 

Once compliance has been attained, organizations should build on that point-in-time success by continually working to improve upon and mature an overall security program. This path is winding and often filled with obstacles. There are times when a helping hand is needed. Engaging a third party to evaluate your current state and provide an objective set of eyes can be helpful in reaching your desired state.