RisknCompliance Blog

Thoughts On Delivering Meaningful Outcomes in Security and Privacy

Tag: SIEM

Security Logging and Monitoring for EHRs

If you are like most medium or large healthcare providers these days, your Electronic Health Record (EHR) environment is likely a very complex one. Such complexity brings with it a fair amount of difficulty in monitoring the environments for security incidents.

Monitoring for security incidents is different from privacy monitoring

Many such healthcare providers have also likely invested in privacy monitoring solutions over the last few years. These investments have been driven largely by the HIPAA Security/Privacy rule or Meaningful Use mandates as well as the  need to be able to identify and respond effectively to privacy incidents or complaints.

Privacy monitoring use cases fall into a fairly limited set of categories – e.g. snooping of neighbor, workforce member or celebrity records. Given the nature and the somewhat narrow definition of these use cases, many organizations appear to be doing a good job in this respect. This is especially the case when organizations have implemented one of the leading privacy monitoring solutions.

While such organizations have notable success with monitoring for privacy incidents,  the same can’t be said for monitoring of security incidents. This is so despite the fact that most of these organizations have invested substantively in security – be it security monitoring solutions such as Security Information and Event Management (SIEM)  orservices such as third party managed security services.

Where is the problem and what might we do about it?

In our experience, the lack of effective security monitoring capabilities across EHR environments can be usually attributed to the lack of appropriate security logs to begin with. And, it is usually not a straightforward problem to solve for more than one reason. The most common reason is the complex nature of the applications and their diverse sets of components or modules. Many of the EHRs were not designed with good security monitoring, in our view.  One can also point to the rather complex and custom workflows at each organization that these EHRs support.

Solving this problem usually requires a specialist effort by personnel who have a strong background in security (and security monitoring). We also need who have specialist knowledge and experience with the respective EHR applications. After all, each EHR application is unique in how the vendors have implemented their security and security logging features.

How could we help?

Our RiskLCM services can help develop a strategy and assist with implementing a sustainable security monitoring program for your EHR(s). We have experience doing this for Epic and Cerner among others and can help you leverage your existing security/privacy monitoring technologies or managed services investments.

Please leave us a message at +1 312-544-9625 or send us a note to RiskLCM@rnc2.com if you would like to discuss further.

You may also be interested in a case study.

Thank you!

This is how the #AnthemHack could have been stopped, perhaps

It has been just over a week since the #AnthemHack was made public.

Over this period, the main stream media and many of the bloggers and commentators,  as usual,  have been all over it.  Many have resorted to some not-so-well-thought-out (at least in my opinion as well as a couple of others1 ) statements such as “encryption” could have prevented it. Some have even faulted HIPAA for not mandating encryption of data-at-rest2.

Amidst all this, I believe there has been some good reporting as well, albeit very few. I am going to point to a couple of articles by Steve Ragan at CSOOnline.com here and here.

I provide an analysis here of perhaps how Anthem could have detected and stopped the breach before the data was exfiltrated. This is based on the assumption that the information published in Steve Ragan’s articles is accurate.

Let’s start with some known information then:

  1. “Anthem, based on data posted to LinkedIn and job listings, uses TeraData for data warehousing, which is a robust platform that’s able to work with a number of enterprise applications”. Quoted from here.
  2. “According to a memo from Anthem to its clients, the earliest signs of questionable database activity date back to December 10, 2014”. Quoted from here.
  3. “On January 27, 2015, an Anthem associate, a database administrator, discovered suspicious activity – a database query running using the associate’s logon information. He had not initiated the query and immediately stopped the query and alerted Anthem’s Information Security department. It was also discovered the logon information for additional database administrators had been compromised.” Quoted from the same article as above.

I went over to the Teradata site to download their Security Administration guide of Release 13 of Teradata Database (download link). I downloaded the guide for an older version from November 2009. I am assuming Anthem is using Release 13 or later and so, isn’t missing the features I am looking at.

Database logging can be challenging sometimes and depending on the features available in your database, the logging configurations can generate a lot of noise. This in turn, may make it difficult to detect events of interest. I wanted to make sure there weren’t such issues in this case.

It turns out TeraData is fairly good in its logging capabilities. Based on the highlighted content, it appears one should be able to configure log generation specifically for a DBA performing a SELECT query on a table containing sensitive data.

=======================================================

TD-Logging

=======================================================

There should not ordinarily be a reason for a DBA to query for sensitive data so this should have been identified as a high risk alert use-case by their Logging and Monitoring program.

I am assuming Anthem also has a Security Information and Event Management (SIEM) solution that they use for security event monitoring. Even a garden variety SIEM solution should be able to collect these logs and raise an immediate alert considering the “high risk” nature of a DBA trying to query for sensitive data.

This alert should have gone to someone that is accountable or responsible for security incident response. It appears that didn’t happen. This is symptomatic of a lack of “ownership” and “accountability” culture, in my view. For a case of this nature, I strongly recommend the IT owner (e.g. Manager or Director of the Database Team) being on point to receive such alerts involving sensitive data. Your Security Operations folks may not necessarily know the context of the query and therefore the high risk nature of it. I talked about this in a guest post last month. See the last dot point in this post.

As quoted at #3 above, it appears one of the DBAs discovered someone using his/her credentials and running that query. You certainly don’t want to leave it to the DBA to monitor his own actions. If this was a malicious DBA, we might be talking about a major breach caused by an insider and not a Advanced Persistent Threat (APT) actor as the Anthem breach appears to be.  But then, I digress.

If the high risk anomalous DBA activity had been discovered immediately through the alert and if appropriate incident response steps had been initiated, it is possible that Anthem may have been able to stop the breach before the APT actor took the data out of the Anthem network.AnthemHack Tweet

So, if we come to think of it, some simple steps of due diligence in establishing security and governance practices might have helped avoid a lot of pain to Anthem not to mention a lifetime of hurt to the people and families impacted by the breach.

Here then are some take-aways if you would like to review your security program and want to make some changes:

  1. You may not need that shiny object. As explained above, an average SIEM solution can raise such an alert. We certainly don’t need that ‘big data” “analytics” solution costing 100s of thousands or millions of dollars.
  2. Clarity in objectives3. Define your needs and use cases before you ever think of a tool or technology. Even if we had a fancy technology, it would be no use if we didn’t identify the high risk use-case for monitoring the DBA activity and implement an alert for it.
  3. Process definition and speed of incident response. People and process aspects are just as important (if not more than) as the technology itself. Unfortunately, we have too many instances of expensive technologies not being effective because we didn’t design and implement the associated people/process workflows for security monitoring and timely incident response.
  4. Ownership and accountability. I talked about this topic last month with a fair amount of detail and examples. While our Security Operations teams have their job to do in specific cases, I believe that the IT leadership must be “accountable” for security of the data collected, received, processed, stored or transmitted by their respective systems. In the absence of such an accountability and ownership culture, our security monitoring and response programs will likely not be effective.
  5. Focus on quick wins. If we look at our environments with inquisitive eyes and ears, most of us will likely identify quick wins for risk reduction. By quick wins, I am referring to actions for reducing higher risk levels that we can accomplish in weeks rather than months, without deploying a lot of resources. Not all of our risk management action plans have to necessarily be driven by formal projects. In the context of this Anthem example, it should be a quick win to implement an alert and have the database manager begin to watch for these alerts.
  6. Don’t accept pedestrian risk assessments and management. If you go back and look at your last risk assessment involving a sensitive database for example, what risks were identified? What were the recommendations? Were these recommendations actionable or some “template” statements? Did the recommendations identify quick-win risk reduction opportunities? Did you follow through to implement the quick wins? In other words, the quality of a risk assessment must be solely determined by the risk reduction opportunities that you were able to identify and the outcomes you were able to accomplish within a reasonable period of time. The quality of paper deliverables, methodology etc. are not nearly as important, not to say that they don’t matter.
  7. Stay away from heavy weight security frameworks. We talked about this last year. I’ll probably have more to say about it in another post. Using #AnthemHack as an example, I plan to illustrate how a particular leading security framework wouldn’t be very helpful. In fact, I believe that using heavy weight security frameworks can be detrimental to most security programs. They take a lot of time and precious resources not to mention the focus away from accomplishing risk reduction outcomes that truly matter.
  8. Effective governance and leadership. Last but not the least, the need for leadership and governance should come as no surprise. None of the previous items on this list can be truly accomplished without an emphasis on governance and leadership starting right at the board level and across the executive leadership.

I hope the analysis and recommendations are useful to you.

Remember, while the techniques employed by APT actors may be advanced and persistent, the vulnerabilities they exploit are often there only because we didn’t do some basic things right or perhaps we made it too hard and complicated on ourselves to do it right.

References for additional reading

1 Why even strong crypto wouldn’t protect SSNs exposed in Anthem breach , Steven M. Bellovin

http://arstechnica.com/security/2015/02/why-even-strong-crypto-wouldnt-protect-ssns-exposed-in-anthem-breach

Even if Anthem Had Encrypted, It Probably Wouldn’t Have Helped, Rich Mogull

https://securosis.com/blog/even-if-anthem-encrypted-it-probably-wouldnt-have-mattered

 

2 I like the fact that the HIPAA Security Rule is not prescriptive, except… , Kamal Govindaswamy

http://rnc2.com/blog/regulatory-compliance/hipaahhitech/like-fact-hipaa-security-rule-prescriptive-except/

 

3 Security Analytics Lessons Learned — and Ignored!, Anton Chuvakin

http://blogs.gartner.com/anton-chuvakin/2015/02/09/security-analytics-lessons-learned-and-ignored/

Patient Portals – Make or Break

Like many other Health IT initiatives today, the primary driver for patient portals is regulatory in nature. Specifically, it is the Meaningful Use requirements related to view,  download or transmit and secure messaging. However, the biggest long term benefit of the portals might be what they can do for patient engagement and as a result, to the providers’ business in the increasingly competitive and complex healthcare marketplace in the United States.

The objective of this post is to discuss the security aspects of patient portals, specifically, why the current practices in implementing these portals could pose a big problem for many providers. More importantly, we’ll discuss specific recommendations for due diligence actions that the providers should take immediately as well as in the longer term.

Before we get to discuss the security aspects, I think it is important to “set the stage” by discussing some background on patient portals. Accordingly, this post covers the following areas in the indicated sequence:

1. What are patient portals and what features do they (or could) provide?

2. Importance of patient engagement and the role of patient portals in patient engagement

3. The problem with the current state in Health IT and hence the risks that the portals bring

4. Why relying on regulations or vendors is a recipe for certain failure?

5. What can/should we do (right now and in the future) –  Our recommendations

1. What are Patient Portals and what features do they (or could) provide?

I would draw on information from the ONC site for this section. Here is the pertinent content, to quote from the ONC site:

A patient portal is a secure online website that gives patients convenient 24-hour access to personal health information from anywhere with an Internet connection. Using a secure username and password, patients can view health information such as:

• Recent doctor visits

• Discharge summaries

• Medications

• Immunizations

• Allergies

• Lab results

Some patient portals also allow patients to:

• Exchange secure e-mail with their health care teams

• Request prescription refills

• Schedule non-urgent appointments

• Check benefits and coverage

• Update contact information

• Make payments

• Download and complete forms

• View educational materials

The bottom-line is that patient portals provide means for patients to access or post sensitive health or payment information. In the future, their use could expand further to include integration with mobile health applications (mHealth) and wearables. Last week’s news from EPIC should provide a sense for things to come.

2. Importance of patient engagement and the role of patient portals in patient engagement

As we said above, the primary driver for patient portals so far has been the Meaningful Use requirements related to view,  download or transmit and secure messaging. However, the biggest long term benefit of the portals might be what they can do for patient engagement and becoming a key business enabler for providers.

The portals are indeed a leading way for providers to engage with patients, as can be seen in this graphic from the 2014 Healthcare IT Priorities published by InformationWeek1.

image

Effective patient engagement of course can bring tremendous business benefits, efficiencies and competitive edge to providers.

From a patient’s perspective, the portals can offer a easier method for interacting with their providers which in turn has its own benefits for patients. To quote from the recently released HIMSS report titled “The State of Patient Engagement and Health IT”2

A patient’s greater engagement in health care contributes to improved health outcomes, and information technologies can support engagement.

In essence, the importance of patient portals as a strategic business and technology solution for healthcare providers doesn’t need too much emphasis.

3. The problem with the current state in Health IT and hence the risks that the portals bring

In my view, the below quote from the cover page of the 2014 Healthcare IT Priorities Report published by InformationWeek1 pretty much sums it up for this section.

Regulatory requirements have gone from high priority to the only priority for healthcare IT.

We all know what happens when security or privacy programs are built and operated purely to meet regulatory or compliance objectives. It is a shaky ground at best. We talked about it in one of our blog posts last year when we called for a change in tone and approaches to healthcare security and privacy.

4. Why relying on regulators or vendors is a recipe for certain failure of your security program?

It is probably safe to say that security in design and implementation is perhaps not the uppermost concern that HealthIT vendors have (certainly not the patient portal vendors in my opinion) today. To make it easy for them, we have lackluster security/privacy requirements in the regulation for certifying Electronic Health Records.

Consider the security and privacy requirements (yellow in this pdf) that vendors have to meet in order to obtain EHR certification today. You will see that the certification criteria are nearly not enough to assure the products are indeed secure enough before the vendors can start selling them to providers. And then, the administration or enforcement of the EHR certification program has been lacking as well in the past.

If you consider a risk relevant set of controls such as the Critical Security Controls for Effective Cyber Defense, you will see that the certification criteria are missing the following key requirements in order to be effective in today’s security threat landscape:

· Vulnerability assessments and remediation

· Application Security Testing (Including Static and Dynamic Testing)

· Security training for developers

· Penetration tests and remediation

· Strong Authentication

Think about using these applications to run your patient portals!

If you are a diligent provider, you will want to make sure that the vendor has met the above requirements even though the certification criteria do not include them. The reality though may be different. In my experience, providers often do not perform all the necessary due diligence before purchasing the products.

And then, when providers implement these products and attest to Meaningful Use, they are expected to do a security risk analysis (see the green highlighted requirement in the pdf). In my experience again, risk analysis is not performed in all cases. Of those that perform them, many are not really risk assessments.

The bottom-line? … Many providers take huge risks in going live with their patient portals that are neither secure nor compliant (Not compliant because they didn’t perform a true risk analysis and mitigate the risks appropriately).

If you look again (in 1 above) at the types of information patient portals handle, it is not far-fetched to say that many providers may have security breaches waiting to happen. It is even possible that some have already been breached but they don’t know yet.

Considering that patient portals are often gateways to the more lucrative (from a hacker’s standpoint) EHR systems, intruders may be taking their time to escalate their privileges and move laterally to other systems once they have a foothold in the patient portals. Considering that detecting intrusions is very often the achilles heel of even the most well-funded and sophisticated organizations,  it should be a cause for concern at many providers.

5. What can/should we do (right now and in the future) –  Our recommendations

It is time to talk about what really matters and some tangible next steps …

What can or must we do immediately and in the future?

Below are our recommendations for immediate action:

a) If you didn’t do the due diligence during procurement of your patient portal product, you may want to ask the vendor for the following:

· Application security testing (static and dynamic) and remediation reports of the product version you are using

· Penetration testing results and remediation status

· If the portal doesn’t provide risk based strong (or adaptive) authentication for patient and provider access, you may insist on the vendor committing to include that as a feature in the next release.

b) If you didn’t perform a true security risk analysis (assessment), please perform one immediately. Watch out for the pitfalls as you plan and perform the risk assessment. Make sure the risk assessment includes (among other things) running your own vulnerability scans and penetration tests both at network and application layers.

c) Make sure you have a prioritized plan to mitigate the discovered risks and of course, follow through and execute the plan in a timely manner.

Once you get through the immediate action steps above, we recommend the below action items to be included in your security program for the longer term:

a) Implement appropriate due diligence security measures in your procurement process or vendor management program.

b) Have your patient portal vendor provide you the detailed test results of the security requirements (highlighted yellow in the attachment) from the EHR certifying body. You may like to start here (Excel download from ONC) for information on the current certification status of your patient portal vendors and the requirements they are certified for.

c) Ask the vendor for application security (static and dynamic) and pen test results for every release.

d) Segment the patient portal appropriately from the rest of your environment (also a foundational prerequisite for PCI DSS scope reduction if you are processing payments with credit/debit cards).

e) Perform your own external/internal pen tests every year and scans every quarter (Note : If you are processing payments with your payment portal,  the portal is likely in scope for PCI DSS. PCI DSS requires you to do this anyway).

f) Conduct security risk assessments every year or upon a major change (This also happens to be a compliance requirement from three different regulations that will apply to the patient portal –  HIPAA Security Rule, Meaningful Use and PCI DSS, if processing payments using credit/debit cards).

g) If you use any open source modules either by yourself or within the vendor product,  make sure to apply timely patches on them as they are released.

h) Make sure all open source binaries are security tested before they are used to begin with.

i) If the vendor can’t provide support for strong authentication,  look at your own options for proving risk based authentication to consumers. In the meanwhile, review your password (including password creation, reset steps etc.) to make sure they are not too burdensome on consumers and yet are secure enough.

j) Another recommended option is to allow users to authenticate using an external identity (e.g. Google, Facebook etc. using OpenID Connect or similar mechanisms) which may actually be preferable from the user’s standpoint as they don’t have to remember a separate log-in credential for access to the portal. Just make sure to strongly recommend that they use 2 step verification that almost all of these social media sites provide today.

k) Implement robust logging and monitoring in the patient portal environment (Hint : Logging and Monitoring is not necessarily about implementing just a “fancy” technology solution. There is more to it that we’ll cover in a future post)

In summary, there is just too much at stake for providers and patients alike to let the status quo of security in patient portals continue the way it is. We recommend all providers take priority action considering the lasting and serious business consequences that could result from a potential breach.

As always, we welcome your thoughts, comments or critique. Please post them below.

References

1 2014 Healthcare IT Priorities published by InformationWeek
2 The State of Patient Engagement and Health IT(pdf download)

 Recommended further reading

Patient engagement – The holy grail of meaningful use
Patient portal mandate triggers anxiety
MU Stage 2 sparks patient portal market

PCI Breaches – Can we at least detect them?

Almost all Payment Card Industry (PCI) breaches over the past year, including the most recent one at Supervalu appear to have the following aspects in common:

1. They involved some compromise of Point of Sale (POS) systems.

2. The compromise and breaches continued for several weeks or months before being detected.

3. The breaches were detected not by the retailer but by some external entity – FBI, the US Secret Service, Payment processor, card brands, issuing bank etc.

4. At the time the breach was disclosed, the retailers appear to have had a passing PCI DSS certification.

Anyone that has a reasonable understanding of the current Information Security landscape should know that it is not a matter of “if” but “when” an organization will get compromised. Given this humbling reality, it only makes sense that we must be able to detect a compromise in a “timely” manner and hopefully contain the magnitude of the breach before it gets much worse.

Let’s consider the following aspects as well:

  1. PCI has one of the more prescriptive regulations in the form of PCI DSS and PA DSS than any other industry. As a case in point, consider the equivalent regulations for Electronic Health Records systems (EHRs) in the United States – the EHR Certification regulation (PA DSS equivalent) requirements highlighted yellow in this document and the Meaningful Use regulation (PCI DSS equivalent) requirements highlighted green. You will see that the PCI regulations are a lot more comprehensive both in breadth and depth.
  1. PCI DSS requires merchants and service providers to validate and document their compliance status every year. For the large retailers that have been in the news for the wrong reasons, this probably meant having a external Qualified Security Assessor (QSA)  performing a on-site security assessment and providing them with a passing Report on Compliance (ROC) every year.
  1. As for logging and monitoring requirements that should help with detection of a potential compromise,  both PCI DSS (Requirement 10)  and PA DSS (Requirement 4) are as detailed as they get in any security framework or regulation I am aware of.
  1. Even if you think requirement #10 can’t help detect POS malware activity, there is PCI DSS requirement 12.2 that requires a security risk assessment to be performed at least once a year. The risk assessment must consider the current threats and vulnerabilities. Given the constant stream of breaches, one would think that the POS malware threats are accounted for in these risk assessments.
  1. These large merchants have been around for a while and are supposed to have been PCI DSS compliant for several years. And so, one would think they have appropriate technologies and processes to at least detect a security compromise that results in the scale of breaches they have had.

So, what do you think may be the reasons why the retailers or the PCI regulations are not effective in at least detecting the breaches? More importantly, what changes would you suggest, both to the regulations and also to how the retailers plan and execute their security programs? Or perhaps even to how the QSAs perform their assessments in providing passing ROCs to the retailers?

I’m keen to hear your thoughts and comments.

Let’s talk some “real” insider threat numbers – How can Access Governance and SIEM be useful as effective safeguards?

If you have been following some of our posts, you probably realize that we don’t advocate security for the sake of security. Nor do we like to do compliance for the sake of compliance though you may not have much choice there if the compliance requirements are mandated by external regulations such as industry regulations (e.g. PCI DSS, NERC CIP etc.) or government regulations (e.g. HIPAA, GLBA, SOX etc.). On the other hand, we think that every investment in security projects or operations (beyond what is required for routine business support) must be justifiable in terms of the risk(s) that we are trying to mitigate or eliminate. And the allocation of IT resources and budgets must be prioritized by risk level which in turn requires every IT organization to conduct periodic risk assessments  and rank the risks by severity.  This probably sounds all too obvious but we still see a lot of security purchasing decisions being made that are not based on formal risk assessments or discernable risk-aligned  priorities. BTW, I talk about the quality of risk assessments in another post.

In this post, I would like to go over some “real” numbers on insider threats, as we know from a few recent survey reports. More importantly, I’ll cover how Access Governance and Security Information and Event Management (SIEM) can be effective safeguards in mitigating risks from insider threats.  If you are not up to speed on what Access Governance (sometimes also referred to as Access Assurance) includes, I would point you here (may need registration).  For SIEM, I would point you here.

It probably needs an explanation as to why I chose Access Governance and SIEM for this discussion. Insider threats, by definition, are caused by people  (employers, contractors, partners etc.) whose identity is known to the organization and have been provided some level of access to one or more of the organization’s information systems.  Access Governance can be both an effective detective control (through access reviews) and preventative control (through role based access provisioning and access remediation) for user access. SIEM can be an effective control for detecting anomalous, suspicious  or  unauthorized user activities. When properly integrated, Access Governance and SIEM  solutions can help achieve substantial reduction of risks from insider threats.

Below is a discussion of findings related to insider threats from recent reports. Also provided are notes on how effective implementations of Access Governance and SIEM processes or technologies can be useful safeguards against these threats. I use findings from three recent reports for the analysis – 2010 Verizon Data Breach Investigations Report (DBIR), 2010 CyberSecurity Watch Survey (CSWS)and Securosis 2010 Data Security Survey (SDSS).

Size and significance of Insider Threats

Report

Finding

DBIR

48% of all breaches were attributed to internal agents

CSWS

“The most costly or damaging attacks are more often caused by insiders (employees or contractors with authorized access)”

“It is alarming that although most of the top 15 security policies and procedures from the survey are aimed at preventing insider attacks, 51% of respondents who experienced a cyber security event were still victims of an insider attack. This number is holding constant with the previous two surveys (2007 and 2006)

Insider incidents are more costly than external breaches, according to 67% of respondents

SDSS

Among respondents who knew of data breaches in their own organizations, 62 percent said malicious intentions were behind them. Insider breaches comprised 33 percent of incidents, hackers comprised 29 percent, and the remaining breaches were accidental.

As one can infer from these findings, insider threats are the cause of at least as many security breaches as external threats. It also appears that the cost of breaches caused by internal threats could be higher than those caused by external threats.

Intentional Vs Accidental

Report

Finding

DBIR

90% of these internal agents’ caused breaches were the result of deliberate and malicious activity.

CSWS

Insiders most commonly expose private or sensitive information unintentionally, gain unauthorized access to/use of information systems or networks and steal intellectual property

SDSS

Among respondents who knew of data breaches in their own organizations, 62 percent said malicious intentions were behind them. Insider breaches comprised 33 percent of incidents, hackers comprised 29 percent, and the remaining breaches were accidental.

It appears from the findings that insiders could be causing breaches intentionally more often than accidentally. Access Governance can help reduce malicious insider risk  by enforcing “least privilege” user access and "segregation of duties" through role based access provisioning, access reviews and remediation of improper access. On the other hand, a properly implemented SIEM solution can be an effective deterrent (as a detective control) to malicious insider threats by logging user activities, correlation of user activities and alerting on suspicious activities by the user. By suitable integration of SIEM and Access Governance solutions, it is possible to analyze user activities (obtained from SIEM) against a user’s role in the organization and hence what the user is authorized to do (obtained from Access Governance).

Cause and prevention

Report

Finding

DBIR

51% of these internal agents’ caused breaches involves regular users or employees, 12% involved accounting or finance staff and 12% involved network or systems administrators

“In general, employees are granted more privileges than they need to perform their job duties and the activities of those that do require higher privileges are usually not monitored in any real way.”

“Across all types of internal agents and crimes, we found that 24% was perpetrated by employees who recently underwent some kind of job change. Half of those had been fired, some had resigned, some were newly hired, and a few changed roles within the organization.”

“With respect to breaches caused by recently terminated employees, we observed the same scenarios we have in the past: 1) the employee’s accounts were not disabled in a timely manner, and   2) the employee was allowed to “finish the day” as usual after being notified of termination. This obviously speaks to the need for termination plans that are timely and encompass all areas of access (decommissioning accounts, disabling privileges, escorting terminated employees, forensic analysis of systems, etc.)”

CSWS

“The most costly or damaging attacks are more often caused by insiders (employees or contractors with authorized access)”

“It is alarming that although most of the top 15 security policies and procedures from the survey are aimed at preventing insider attacks, 51% of respondents who experienced a cyber security event were still victims of an insider attack. This number is holding constant with the previous two surveys (2007 and 2006)

The DBIR findings clearly illustrate the need for organizations to enforce least privilege access through business need-to-know (managing user access based on a user’s role), periodic review of user access (access reviews and certification) and prompt remediation of improper user access.  Access Governance solutions can help achieve these objectives effectively as well as efficiently.

The CSWS finding seems to suggest a problem with the enforcement of organization’s policies related to user access.  As mentioned above, a properly implemented Access Governance program and solution can help with effective enforcement of user access policies.

To conclude, it is obvious that risk management of insider threats needs to be a key focus area of any Information Security  or Risk Management program. An effective Access Governance and SIEM program can help with significant mitigation of the insider risk.

————————————————————————

RisknCompliance Consulting Services Note

We at RisknCompliance have extensive advisory and implementation experience in the Access Governance and SIEM areas.

Please contact us here if you would like to discuss your needs. We will be glad to talk to you about how we could be of assistance.


Logging for Effective SIEM and PCI DSS Compliance …. UNIX, Network Devices and Databases

In one of my previous blogs, I covered the importance of logging the “right” events for an effective Log Management or Security Information and Event Management (SIEM) deployment … see here or here for a discussion on the two technologies. The blog also provided a suggested listing of the Windows or Active Directory events that you might want to log from a PCI DSS Compliance standpoint.

Clearly, no amount of investment in your Log Management or SIEM solution is going to do much good, unless you have been able to generate all the right logs to begin with … see a related discussion with the recognized PCI Expert and Author, Dr. Anton Chuvakin here.

I would like to extend my suggested list in the previous post to cover a few other systems here,  specifically UNIX/LINUX, Network Devices and Databases. Note that this list is only a starting point so you can work with the respective System Specialists or Administrators in your organization to generate these events.

UNIX/LINUX Logging for Effective SIEM and PCI DSS Compliance

 

Logging of Network Devices for Effective SIEM and PCI DSS Compliance

Database Logging for Effective SIEM and PCI DSS Compliance