Brian Pennington

A blog about Cyber Security & Compliance


Risk management

Tripwire’s second installment of research on the state of risk-based security management with the Ponemon Institute has once again revealed some interesting insights into the workings of the IT Department. 

The survey covers risk-based security metrics and evaluates the attitudes of 1,321 respondents (749 U.S. and 571 U.K.) from IT security, IT operations, IT risk management, business operations, compliance/internal audit and enterprise risk management.

The key findings from the survey are:

  • 75% of respondents say metrics are ‘important’ or ‘very important’ to a risk-based security program
  • 53% don’t believe or are unsure that the security metrics used in their organizations are properly aligned with business objectives
  • 51% didn’t believe or are unsure that their organizations metrics adequately convey the effectiveness of security risk management efforts to senior executives

When asked, “Why don’t you create metrics that are well understood by senior executives?”:

  • 59% said the information is too technical to be understood by non-technical management
  • 48% said pressing issues take precedence
  • 40% said they only communicate with executives when there is an actual security incident
  • 35% said it takes too much time and resources to prepare and report metrics to senior executives
  • 23% of U.S. respondents and 20% of those in the U.K. think security metrics can be ambiguous, which may lead to poor decisions
  • 18% said senior executives are not interested in the information

 So, why isn’t communication between security professionals and executives more effective? Respondents were asked to select all the factors that apply from a list of nine possible reasons, and their answers present a wide range of serious challenges. The top three responses include organizations hampered by siloed information, presenting information not easily understood by non-technical managers, and the practice of filtering “bad news” from the C-suite.

  • 68% of U.S. and 57% of U.K. respondents say communications are confined to one department or line of business
  • 61% say the information is too technical and occurs at too low a level
  • 59% state that negative facts are filtered before getting to executives

Commenting on these results, Dr. Larry Ponemon, chairman and founder of the Ponemon Institute, said,

Even though most organizations rely on metrics for operational improvement in IT, more than half of IT professionals appear to be concerned about their ability to use metrics to communicate effectively with senior executives about security

These results correlate with the dozens of conversations we have been having with CISO’s across the globe,” said Rekha Shenoy, vice president of marketing and corporate development at Tripwire

CISO’s talk about the importance of leveraging metrics as a way to influence business leadership and build a risk management practice within their companies. Unfortunately, they struggle with the bigger challenge of producing meaningful metrics while those they use are rarely aligned with business goals

Tripwire summary

While the majority of security professionals agree they need significant amounts of data in order to build a culture of ac­countability, they aren’t sure how to distill this information into metrics that are understandable, relevant and actionable to senior business leadership. Business metrics tend to reflect the value of strategic goals rather than technical goals, and may prioritize cost over less tangible security benefits. Security metrics tend to reflect operational goals and may prioritize technical improvement over business context.

Four Things You Need to Know About Risk Analysis

Guest Blog: IDexperts Chris Apgar.

Every privacy professional knows that risk analysis is a foundation for successful information privacy and security, just as flossing your teeth is a foundation for good oral health. If you’re in healthcare, you also know that risk analysis is one of the five core Office for Civil Rights (OCR) “culture of compliance” requirements, and a prerequisite to receiving “meaningful use” dollars for implementing electronic health records (EHR). But what you may not know, according to nationally recognized information security expert and former HIPAA Compliance Officer Chris Apgar, is that compliance is not the biggest reason for conducting ongoing risk analysis. The biggest reason is that it can save your business.

OCR audits are proceeding, and failure to conduct risk analysis can result in a finding of “willful neglect” with penalties up to $50,000 per incident and up to $1.5 million per calendar year for the same type of violation (and any such finding will typically involve multiple types of violations). That risk, alone, justifies the cost of conducting risk analysis. A thorough risk analysis also provides a strategic roadmap for security spending, but Apgar says that even now, when he speaks to groups about medical data privacy, only about 1/3 of all healthcare organizations that are not seeking “meaningful use” dollars indicate that they’ve conducted risk analysis, and he points out that this is dangerous because by deferring the analysis, they may fail to identify other risks such as lawsuits, civil penalties, and loss of reputation that could damage or destroy their business.

Here are three other things Chris Apgar says you need to know risk analysis:

  • Confidentiality is not enough. The three pillars of security are confidentiality, availability, and integrity, and risk analysis needs to account for all of these. Yes, you want to prevent data breach, but that’s not enough. For example, what happens if a patient is in critical care, systems go down, and doctors lose access to critical information they need to make medical decisions?  Data corruption can be even more serious because if doctors unknowingly make bad healthcare decisions based on corrupt information, lives can be lost.
  • Technical security is not enough. Apgar says that, too often, when an organization looks at risks, they look only on the digital side, but PHI risks extend far beyond technical infrastructure. You need to look at every place where PHI lives, in any form, and everyone who touches it. For example, encryption can mitigate risk  in case of a security related incident involving electronic records, but  you can’t encrypt paper.  So if paper records are lost, by definition, that’s a security incident and potentially a reportable breach. People and process risks also have to be assessed as part of the security plan. One privacy officer that Apgar worked with pointed out that he and other compliance professionals in the organization had to be considered as organizational assets and as liabilities, because at that time, they were the only ones who knew how to respond in case of an incident, and if they were unavailable, the organization would be at risk.
  • There’s more than one way to become a covered entity. A new Texas healthcare privacy law goes into effect this month. Apgar says that, in addition to non-compliance penalties over and above the federal, it has a broader definition of covered entities.  Under the Texas law, if an organization handles any sort of electronic healthcare information, no matter its role in the healthcare system, it is covered by the new privacy requirements and considered a covered entity. So, for example, a small dental practice that transmits HIPAA covered transactions in Texas is now a covered entity under Texas law.  In addition, business associates and subcontractors could now face non-compliance fines from both OCR and state of Texas. Other states, including California and Massachusetts, also have high levels of regulation around healthcare information. A thorough and ongoing risk analysis program is necessary to keep organizations of all sizes abreast of new risks and requirements at state and federal levels.

Apgar has a number of practical recommendations for conducting risk analysis.

  • Successful risk analysis begins with a thorough inventory that accounts for all assets: digital, physical, and human. He points out that you need that inventory, anyway, to create a disaster recovery plan, and that keeping that inventory current makes the initial risk analysis and updates relatively simple because you have a baseline to work from.
  • Think of things inside the organization that can hurt you. “Threats” are unpredictable outside factors such as natural disasters and hackers that require response plans, but there are “vulnerabilities” that you can address to head off trouble. For example, you can help preventing network attacks by putting in place a process to ensure security patches are always kept up to date.
  • The risk analysis needs to rate risks both in terms of likelihood and in terms of potential harm or impact. For example, tsunamis are unlikely in Oklahoma so they don’t need to be part of an Omaha hospital’s disaster recovery plan, and unauthorized access to one patient record showing on a computer screen is likely to cause far less damage than a stolen computer full of patient records in lab’s business office. Once you’ve made a reasonable assessment of the likelihood and potential impact, it will become clear how best to spend your security budget and resources.
  • Don’t stop with the risk analysis. Meaningful use requires risk analysis, documentation, a mitigation plan, and implementation of a risk management program. Whether or not your organization is seeking meaningful use dollars, knowing about a risk offers little protection if you don’t act on the knowledge and implement steps to manage risk throughout the year.
  • If you bring in experts to conduct a risk analysis or to help your staff conduct one, look for someone who has done this before in healthcare and who has a track record with your type of healthcare business. Make sure their products and services address more than just technical security, and check references, of course, but also ask colleagues about their reputation. Word travels fast in the healthcare industry, and word on the street may tell you things that you won’t find out in a reference check.

Chris Apgar says the most critical thing to realize about risk analysis is that it stretches beyond what the regulations require. “There are so many other risks: the risk of being sued, of losing your practice, of causing harm to your patients. Yes, doing risk analysis costs time and money, but not doing it is a good way to lose more money or lose your business.”


The State of Risk-Based Security Management

The Tripwire sponsored Ponemon study called “The State of Risk-Based Security Management: United States” is designed to discover what organizations are doing with respect to Risk-based Security Management (RBSM), where RBSM is defined as the application of rigorous and systematic analytical techniques to the evaluation of the risks that impact an organization’s information assets and IT infrastructure. RBSM can be considered one component of a wider enterprise risk management system.

My summary of the document is below.

  • 77% express significant or very significant commitment to RBSM
  • yet 52% have a formalized approach to it
  • 46% have actually deployed any RBSM program activities

Of those that have a formal function, program or set of activities dedicated to RBSM, 74% have partially or completely deployed some or all RBSM activities. It appears that having a formalized strategy or plan for RBSM is an important precursor for ensuring that RBSM activities are deployed

41% of respondents say that their organizations do not categorize their information according to its importance to the organization. Organizations must take this step to make informed, rational decisions about what data is most critical to protect.

Only 45% have specific metrics for determining RBSM effectiveness. Those responsible for the program need a scorecard that demonstrates its success in order to secure funding and resources.

Few organizations have achieved a balanced approach with their preventive and detective controls. While most (80 to 90%) deploy the majority of necessary and appropriate preventive controls, only around half deploy the majority of necessary detective controls.

30% of organizations have no formal RBSM strategy for the enterprise, and almost a quarter (23%) have only an informal or ad hoc strategy.

The existence of a formal RBSM function, program or set of activities

  • Yes 52%
  • No 48%

The existence of a risk management strategy

  • 30% Do not have a strategy
  • 24% Formal but inconsistently applied strategy
  • 23% Informal or “ad hoc”strategy
  • 23% Formal and consistently applied strategy

The US and UK (25 and 36%, respectively) are less concerned about regulatory non-compliance than Germany and the Netherlands (60 and 58%, respectively). This can be attributed to the strict rules governing the handling of personal and sensitive information in Germany and the Netherlands.

Organizations in Germany and the Netherlands have more concern about the cloud than the US and UK. Specifically, 65%t of German organizations and 59% of organizations in the Netherlands are concerned or very concerned about software as a cloud service.  In contrast, 46% of US and 48% of UK organizations are concerned or very concerned.

US organizations are far more concerned about the human factor risk to their IT infrastructure today and in the immediate future. Specifically, 71% of respondents from US organizations say they are concerned about malicious insiders. In the UK that number drops to 49%.

A larger gap exists between the US and Germany (32%) and the Netherlands (16%). The US and UK are more concerned about employee carelessness (66 and 65%, respectively) than Germany and the Netherlands (34 and 38%, respectively).

Threats to information security faced by organizations

The greatest rise of potential security risk within today’s IT environment

Find the full report here.


Database security and SIEM are the top Risk and Compliance concerns

Image representing McAfee as depicted in Crunc...

The McAfee report Risk and Compliance Outlook: 2012, has been published and has discovered Database Security and Security Information and Event Management (SIEM) were among the top priorities due to an increase in Advanced Persistent Threats (APT).

Database hold the valuable data the criminals are searching for, it therefore follows that Database Security is a growing issue and one flagged as the biggest concern. The report indicates that over one quarter of those surveyed had either had a breach or did not have the visibility to detect a breach. This is a huge concern when considering that most compliance requirements are concerned with knowing if a breach could or has occurred for example Payment Card Industry Compliance (PCI DSS) and the pending European Wide Data Protection Act.

The other major was Security Information Event Management (SIEM) which correlates well with the fears over Database Security with approximately 40% of organizations planning on implementing or update their SIEM solution.

Key findings of the report:

  • Similar to the 2011 survey, there is a positive trend in security budgets for 2012 with 96% of the organizations indicating same or more expenditure on risk and compliance
  • Organization state ‘Compliance’ as the driver for almost 30% of IT projects
  • Software and Appliance are the top choices for Risk and Compliance products. On average, one-third of all organizations prioritized the upgrade/implementation of unique risk and compliance products to address vulnerability assessment, patch management, remediation, governance, risk management, and compliance
  • Survey data showed rapid uptake towards Hosted SaaS and Virtualization. Nearly 40% organizations claim to be moving towards these deployment models in 2012
  • Patch Management frequency is a challenge – almost half of the organizations patch on a monthly basis with one-third doing it on a weekly basis. Just like last year’s analysis, not all companies are able to pinpoint threats or vulnerabilities, as a result, 43% indicate that they over-protect and patch everything they can

“Managing risk through security and compliance continues to be a leading concern for organizations the world over,” said Jill Kyte, vice president of security management at McAfee. “Meeting the requirements of increasingly demanding regulations while reducing exposure to the new classes of sophisticated threats and having an accurate understanding of risk and compliance at any point in time — can be challenging. To address this issue, organizations are looking to ‘best-of-breed’ solutions to manage all aspects of their risk and compliance needs and reduce the amount of time spent managing multiple solutions.”

Some other headline findings of the survey show:

  • Visibility is a pervasive challenge organizations continually face in managing their IT risk posture. The issues revolve around having the visibility to see vulnerabilities within their processes and controlling the ever-changing internal and external threat vectors
  • 80% of the survey respondents recognize the importance of visibility; more than 60% have about the same visibility they had in 2010; 27% improved their visibility since 2010; and 8% now have less visibility compared to 2010
  • The top two controls that respondents have implemented to manage risk and subsequently their compliance postures are the monitoring of databases and of configuration changes for the entire enterprise environment/ infrastructure
  • Approximately 60% of surveyed organizations view SIEM solutions as an important solution to provide real-time visibility into their applications, databases, system performance, and event correlation

A summary of the whole report is below along with a link to the full report.

Risk and Compliance Posture

During 2011, over 60% of the respondents implemented and updated existing tools to improve the visibility and control of their IT processes in an effort to minimize organizational risk. Product groupings include:

  • Risk Management
  • Application, Database and Network Vulnerability Assessment
  • Log Management and Security Information Event Management (SIEM)
  • Database Activity Monitoring
  • Policy Compliance Assessment and Governance Risk and Compliance (GRC)

Respondents indicate that their 2012 implementation and upgrade priorities include

  • Risk Management at 19% and 18% respectively
  • Vulnerability Assessment at 18% and 19%
  • Patch Management at 16% and 21%
  • SIEM at 16% and 21%
  • Further, 48% of the respondents (an increase of 8% over last year) indicate that their organizations have updated/deployed a GRC solution in 2011 in an effort to aggregate and monitor organizational risk and compliance status

Overall it appears that enterprises recognize that they cannot efficiently address risk unless they understand what they are up against and can apply the appropriate controls. Without this knowledge and insight, the effectiveness of any security and compliance efforts cannot be effectively measured against the risks there are:

  • 39% of incidents involved a negligent employee or contractor
  • 37% concerned a malicious or criminal attack
  • 24% involved system glitches including a combination of both IT and business process failures

Mainline cybercriminals continued to automate and streamline their method du jour of high-volume, low-risk attacks against weaker targets. Most victims fell prey because they were found to possess an (often easily) exploitable weakness rather than because they were pre-identified for attack. Given this, it’s not surprising that most breaches were avoidable (at least in hindsight) without difficult or expensive countermeasures

Patch Management

At the time they wrote the report McAfee believed there are over 49,000 known common vulnerabilities and exposures (CVE’s) as reported by US-Cert National Vulnerability Database (NVD).

During 2011 the NVD reported 3,532 vulnerabilities, which translates to about ten new security vulnerabilities being discovered each day. While the rate of newly discovered vulnerabilities is impressive, the good news is that the trend is on a descending path: 4,258 vulnerabilities were reported in 2010 and the peak was in 2008, when almost 7,000 vulnerabilities were reported.

More than half of the surveyed companies indicated they know precisely which assets need to be patched when new threats materialize to prevent the threats from impacting their businesses. Conversely, 15% of the surveyed indicate they are not confident in their ability to know which assets to patch when new threats materialize.

Comparison of patch cycle (weekly, monthly, and quarterly) to confidence levels shows that that as the patching frequency declines so does an organization’s confidence. Specific analysis shows:

  • Organizations with weekly patching practice – 53% feel confident about patching of assets
  • Organizations with monthly patching practice – 49% feel confident about patching of assets
  • Organizations with quarterly patching practice – 43% feel confident about patching of assets


Ever changing threats, data breaches, and IT complexity add additional burdens to the already difficult tasks associated with having the visibility necessary to monitor security events, detect attacks, and assess real and potential damage.

Near real-time visibility is critical to any risk management program in today’s complex and diverse computing environments. Without it, organizations are flying blind.

Similar to last year,

  • approximately half of the respondents spend 6 to 10 hours per month on risk management activities that assess and correlate the impact of threats on their organizations
  •  7% of small organizations (1,000 or less employees) spend 15-20 hours on risk and threat activities
  • 16% of organizations with more than 1,000 employees spent 15-20 hours on risk and threat activities

Policy Compliance and Configuration Challenges in Achieving Compliance

Regardless if an organization views industry standards and compliance mandates as a way to improve their practices or as a necessary evil, implementing standards is just the beginning of the road to compliance.

The real challenge often lies in maintaining compliance over time, especially as compliance standards and mandates evolve and increase in number. Organizations need to recognize:

  • Business and technology boundaries are constantly changing, expanding
  • New technology brings new risks, new processes and thus new compliance issues
  • Businesses require flexibility to maintain competitiveness – rigid controls can hinder flexibility, thus hurt operational effectiveness.

According to the Ponemon Institute

“True Cost of Compliance” study: “…while the average cost of compliance for the organizations in our study is $3.5 million, the cost of non-compliance is much greater. The average cost for organizations that experience non-compliance related problems is nearly $9.4 million.”

Database Security When asked about sensitive database breaches,

  • 12% of the organizations stated that they have experienced a breach
  • 15% “are not sure”

These results indicate weakness in security control effectiveness and a lack of visibility. Conversely, three-fourths of the respondents overall and in particular those from North America, Germany and the UK, indicate that their databases have never been breached.

According to Forrester Research analyst Noel Yuhanna in his most recent database security market overview report:

“The database security market is likely to converge with the overall data security market in the future, as DBMS vendors extend the security features that are bundled with their products”.

Mr Yuhanna’s market insight closely corresponds with our respondents’ use of database security solutions:

  • 49% of the organizations use dedicated database security solutions; McAfee, followed by Oracle, tops the list of database security solution providers
  • 42% of the organizations use DBMS vendor security features to protect their databases
  • As compared to 34% organizations from Brazil, a higher number of organizations from France (66%) and the UK (58%) have dedicated database security solutions. Regional analysis shows 61% of Brazil-based organizations use DBMS vendor security features compared to 36% of the North American organizations. IBM holds a strong market share in North America, France and Germany as compared to its share in APAC and the UK.

The link to the full McAfee report is here.


Could you save 50% on the cost of your Firewall Change Requests?

Tufin, a “Security LifeCycle Management solutions company” claim that with effective Firewall change management a business could reduce the cost of its Firewall management by 50%.

Tufin use research from Frost and Sullivan to support their claim.

Frost & Sullivan reports that “The process of implementing a change request to a firewall is a combination of many tasks that are in most cases manual, unclear and time-consuming. [Tufin] SecureChange TM Workflow automates the request process, substantially reducing the overall IT costs associated with change requests by half annually.”

What is undeniable is the need for effective change management processes and controls for Firewalls if a Firewall, or any other security solution, is to remain efficient and secure.

Firewall change management is a mandated requirement in several legislative and compliance standards, for example the Payment Card Industry Data Security Standard (PCIDSS) has a list of specific controls that should be in place and should be provable, a sample list from the standard is below:

1.1 Obtain and inspect the firewall and router configuration standards and other documentation specified below to verify that standards are complete. Complete the following:

1.1.1 Verify that there is a formal process for testing and approval of all network connections and changes to firewall and router configurations.

1.1.2.a Verify that a current network diagram (for example, one that shows cardholder data flows over the network) exists and that it documents all connections to cardholder data, including any wireless networks.

1.1.2.b Verify that the diagram is kept current.

1.1.3.a Verify that firewall configuration standards include requirements for a firewall at each Internet connection and between any DMZ and the internal network zone.

1.1.3.b Verify that the current network diagram is consistent with the firewall configuration standards

1.1.4 Verify that firewall and router configuration standards include a description of groups, roles, and responsibilities for logical management of network components.

1.1.5.a Verify that firewall and router configuration standards include a documented list of services, protocols and ports necessary for business—for example, hypertext transfer protocol (HTTP) and Secure Sockets Layer (SSL), Secure Shell (SSH), and Virtual Private Network (VPN) protocols.

1.1.5.b Identify insecure services, protocols, and ports allowed; and verify they are necessary and that security features are documented and implemented by examining firewall and router configuration standards and settings for each service.

1.1.6.a Verify that firewall and router configuration standards require review of firewall and router rule sets at least every six months.

1.1.6.b Obtain and examine documentation to verify that the rule sets are reviewed at least every six months.

1.2 Examine firewall and router configurations to verify that connections are restricted between untrusted networks and system components in the cardholder data environment, as follows:

1.2.1.a Verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment, and that the restrictions are documented.

1.2.1.b Verify that all other inbound and outbound traffic is specifically denied, for example by using an explicit “deny all” or an implicit deny after allow statement.

1.2.3 Verify that there are perimeter firewalls installed between any wireless networks and systems that store cardholder data, and that these firewalls deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment.

1.3 Examine firewall and router configurations—including but not limited to the choke router at the Internet, the DMZ router and firewall, the DMZ cardholder segment, the perimeter router, and the internal cardholder network segment—to determine that there is no direct access between the Internet and system components in the internal cardholder network segment

1.3.6 Verify that the firewall performs stateful inspection (dynamic packet filtering). (Only established connections should be allowed in, and only if they are associated with a previously established session.)

1.4.a Verify that mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), and which are used to access the organization’s network, have personal firewall software installed and active.

1.4.b Verify that the personal firewall software is configured by the organization to specific standards and is not alterable by users of mobile and/or employee-owned computers.

6.6 For public-facing web applications, ensure that either one of the following methods are in place as follows:

  •  Verify that public-facing web applications are reviewed (using either manual or automated vulnerability security assessment tools or methods), as follows:
  •  Verify that a web-application firewall is in place in front of public-facing web applications to detect and prevent web-based attacks.

The day to day operation of a business can mean “quick changes” are made to firewalls and other security solutions and are not be recorded but could significantly impact on the businesses security level and the organisation’s ability to maintain compliance.

A spreadsheet could be an answer but configuration changes often involve several tasks, for example testing the change prior to going live. Changes across multiple devices may involve several people as security devices need highly skilled security professionals to manage them. Without an effective process or solution an organisation could be wasting the time of expensive resources and may incur unexpected and costly downtime.

To meet these challenges in a cost-effective manner, Tufin recommends that organizations need to extend IT automation into the domain of network security configuration. Automating the security change lifecycle can help companies to: 

  • Improve network security and uptime
  • Enforce corporate governance
  • Manage risk effectively and proactively
  • Increase operational efficiency
  • Comply with industry and regulatory standards
  • Audit security infrastructure quickly and accurately
  • Improve service levels

Tufin believe the key to effective security change automation solution is a combination of both workflow and security technologies. Generic ticketing and helpdesk systems can route requests to security administrators, but since they have a limited understanding of security processes and compliance policies, they cannot automate and enhance each of the stages in a configuration change, from request and design, through implementation and auditing. A comprehensive security change automation solution will work either alone, or in concert with a standard ticketing system, to provide: 

  • Multiple, customizable change workflows tightly coupled with security and network infrastructure, directory services and compliance policies
  • Automated, proactive risk and compliance analysis as an integral part of the change process
  • Configuration change advisory and automatic verification to reduce the risk of errors and shorten ticket resolution time
  • Separation of duties and enforcement of IT governance
  • A comprehensive audit trail with integrated reporting
  • SLAtracking and high-level monitoring tools to ensure continuous improvement 

The security change lifecycle represents a holistic view of an organization’s security configuration change processes.

A typical security change lifecycle could include the following stages: 

Request: A business user requests a service, most commonly access to an application or network, or IT requests connectivity changes for a new or modified server or application. 

Business Approval: The request is sent for approval to an IT manager to ensure that it is justified. 

Technical Design: An engineer translates the request from its business context into a specific implementation plan on the affected firewalls or devices. 

Risk Analysis: A security manager performs risk analysis and checks the change for compliance. 

Implementation: The change is actually implemented on the network infrastructure by one or more administrators. 

Verification: The user checks that his/her request has been fulfilled. At this stage, a manager can also verify that the implementation was in accordance with the approved design. 

Audit: Periodically, all changes must be audited in order to demonstrate sufficient security levels and compliance with standards. 

Other firewall solutions are available from companies like Firemon and many Firewall vendors have introduced their own solutions for example Check Point. 

Download the Tufin White Paper here.


Create a free website or blog at

Up ↑

%d bloggers like this: