Author: Dr. Philip Cao

Dr. Philip Cao (aka #DrPC), EDBA, MSCS, ZTX-I, CCISO, CISM, CMSC, CCSP, CCSK, CASP, GICSP, PCSPI is a Strategist, Advisor, Educator, Contributor and Motivator. He’s also a Cyber | Zero Trust Strategist & Evangelist and Chief Trust Officer. He has 24 years’ experience in IT/Cybersecurity industry in various sectors & positions.
Posted on

Designing a Quality Management Approach to Cybersecurity

Designing a quality management approach to cybersecurity starts with two sets of security standards, (1) the manufacturer and (2) the organization.

The manufacturer standards should include the mitigation of security vulnerabilities, (OWASP, CVE), based on a specific configuration within a defined architecture. There are only so many situations in which a network device firewall, router, switch, server, desktop, laptop, handheld can be deployed. The software, enterprise resource planning (ERP), utilities, apps, etc., should also be tested for security vulnerabilities before they are released.

We need to weed out the technologists who insist on flying by the seat of their pants. They can expose the organization to unnecessary reputational risks and potential financial and strategic risks. By not documenting security standards, the organization will be not be able to produce consistent outputs. It is impossible to manage quality when nothing is documented; it cannot be validated or verified.

The organization’s security standards need to define how a network device will be implemented. This usually means that only a select list of manufacturers and products that have been tested and meet the organization’s requirements can be purchased. This also means that the security architecture needs to be documented based on those specifications and business requirements. These specifications need to be meaningful, because they will be tested, verified and validated.

Each device or software product needs to have its security standards documented—again, these need to be meaningful. A risk assessment could help to identify what needs to be documented. I also recommend adopting the ISO 9001 approach to product realization. To be effective, security standards need to be consistently documented in a manner that includes specifications. These specifications are grouped as follows:

  • Design—how the device or software fits into the architecture; i.e., internal facing
  • Installation—how the device or software will be installed; i.e., configuration
  • Operations—how the device or software will be used; i.e., standard operating procedure
  • Performance—how should the device or software function; i.e., response times, look, feel, etc.

In quality management, we refer to these specifications as qualifications because they get tested and verified before release. We also call them design qualification (DQ), installation qualification (IQ), operations qualification (OQ) and performance qualification (PQ). These specifications need to be considered as part of the enterprise security architecture during any custom software development or major changes. Rule number one is “No surprises!” The secure software development methodology needs to include specifications for design that eliminate all known vulnerabilities and any organizational attack vectors that are unique to the organization. Any changes need to be retested during the quality assurance (QA) and user acceptance testing phase of development. The QA team needs to include a member from the software side and the technology side.

The results are a fully integrated, seamless approach to managing security vulnerabilities and shutting down those attack vectors. The time spent upfront will save time on the back end, so that management can focus resources on problem management and security events and incidents to gather additional intelligence. The additional benefit is that the security team can more easily detect potential security events and incidents more rapidly.

Organizations should not have to pay out of their own pockets to fix security defects that the manufacturer could have fixed for everyone by adopting a similar quality management approach. If the developer or manufacturer was facilitating this level of testing, it should be able to provide the security standards.
Organizations that purchase products that have known vulnerabilities/defects, nullify their warranties. This increases the organizations’ exposure and liabilities, which means that they will need to carry more insurance and pay for it out of their pockets, further increasing operational costs and lowering revenue because the cost of doing business just got more expensive.

Mark E.S. Bernard, CGEIT, CISA, CISM, CRISC, CISSP, ISO 27001 Lead Auditor

[Source: ISACA]

Posted on

What Can We Learn from New Data On Advanced Persistent Threats?

ISMG’s recent Advanced Persistent Threats Survey, sponsored by Palo Alto Networks, reviews the current advanced threat and APT landscape as well as where traditional security solutions fall short.

Here is what jumps out about APT findings based on ISMG data:

It’s Time to Target the Kill Chain

ISMG’s report covers key trends informing those results as well as how to put those results to work. Our CSO Rick Howard is also interviewed about how organizations should approach 2015 survey investments.

Background on the Survey

The survey was developed by the editorial staff of Information Security Media Group, with the assistance of members of ISMG’s boards of advisers, which include leading information security, IT and risk experts.

This survey was conducted online during the spring of 2014. Key characteristics of the respondent base:

  • 64 percent are from the U.S.
  • 56 percent of respondent organizations employ 500 or fewer employees
  • 44 percent employ between 500 and 10,000+ employees

Top responding industries are:

  • Banking/financial services – 57 percent
  • Technology – 8 percent
  • Professional services – 7 percent

Learn more about APTs and threat prevention

[Source: Palo Alto Networks Research Center]

Posted on

New Indicators of Compromise for APT Group Nitro Uncovered

In mid-July of this year, we noticed yet another legitimate website had been compromised by APT actors and was serving malware. In this case, it was a group commonly referred to as “Nitro,” which was coined by Symantec in its 2011 whitepaper.

As we dug deeper, we found additional compromised legitimate websites and malware from the same group back through March of this year. In most instances, the malware is one commonly referred to as “Spindest,” though we also found “PCClient” and “Farfli” variants in use by the group. We don’t have enough data to say for certain that all of the malware in this blog was delivered via compromised legitimate websites.

Historically, Nitro is known for targeted spear phishing campaigns and using Poison Ivy malware, which was not seen in these attacks.  Since at least 2013, Nitro appears to have somewhat modified their malware and delivery methods to include Spindest and legitimate compromised websites, as reported by Cyber Squared’s TCIRT.  Our findings indicate they are continuing to evolve with the addition of PCClient and Farfli variants.  The Maltego screenshot below shows the activity we describe in this blog.

These events impacted at least the following industries, across four waves:

  • A US based IT Solutions provider;
  • The European office of a major, US based commercial vendor of space imagery and geospatial content;
  • A European leader in power technologies and automation for utilities and industry;
  • A US based provider of medical and dental imaging systems and IT solutions.

In July, Nitro compromised a South Korean clothing and accessories manufacturer’s website to serve malware commonly referred to as “Spindest.”  Of all the samples we’ve tied to this activity so far noted in this blog, this is the only one configured to connect directly to an IP address for Command and Control (C2).  This IP address has been in use by this group for some time, which is interesting since they have evolved other components of their kill chain over time to ensure malware delivery, but oddly not altered their C2 infrastructure. It is simple for companies to block any outbound traffic to this IP, which would negate the effort Nitro put into successfully delivering the malware.

37 AV vendors within VirusTotal properly identify it, and the PE timestamp shows the day before we saw it. In addition, the following three samples were found roughly a week apart from each other, possibly indicating the timing of the waves of activity.

Table 1

SHA256 0a1103bc90725d4665b932f88e81d39eafa5823b0de3ab146e2d4548b7da79a0
MD5 7915aabb2e66ff14841e4ef0fbff7486
File Name update.exe
File Size 106496
First Seen 2014-07-24 11:54:02
C2 IP 223.25.233.248

The next sample we found is commonly known as PCClient, which is not malware previously tied to this group.  We discovered this, and many of the following samples, through historic IP resolution overlap between the same domains alternately resolving to either the 223.25.233.248 or 196.45.144.12. The second IP has also not been reported as tied to this group before.  However, this shifting of IP resolutions back and forth indicates Nitro is in control of these domains. It also makes is fairly easy for any Infosec team to reach the same conclusion we did, which again negates their use both of a previously unreported domain and IP for C2, as well as a new family of malware. 25 AV vendors within VirusTotal properly classify this sample as malware.  Its PE timestamp was 8 July, almost a week prior when we first saw it.

Table 2

SHA256 8aef92a986568ba31729269efa31a2488f35920d136ab41cb6fce55fd8e0b4b7
MD5 7522baef20df95eeeeafdf4efe3aac3c
File Name lsm.exe
File Size 65536
First Seen 2014-07-15 11:48:33
C2 URL xenserver.ddns[.]net
Resolution 196.45.144.12

The next sample was another Spindest variant and had the same timestamp as the aforementioned PcClient sample.  In addition, Nitro chose to use the same C2 for this sample, making it easy to both find and tie to the group. 41 AV vendors within VirusTotal properly classify this sample as malware.

Table 3

SHA256 995bc16a5c2c212b57ba00c2376ac57c8032c7f2b1d521f995a5e1d49066d64d
MD5 6527ba8baab0f86b0ffb6178247772c4
File Name install_reader11_en_aaa_aih.exe
File Type PE
File Size 81920
First Seen 2014-07-09 16:31:26
C2 URL xenserver.ddns[.]net
Resolution 196.45.144.12

The next wave of activity we found took place in mid-May. Both samples were Spindest variants with the same PE timestamp of 15 May. While neither MD5s for C2 match, the aforementioned link to a post by Cyber Squared’s TCIRT did document Nitro using Spindest variants with the same file name starting late December last year. In that case they used the historic C2 IP we note in Table 1 in this blog. 34 AV vendors within VirusTotal properly classify the first sample as malware, and 40 AV Vendors the second sample.

Table 4

SHA256 e7f2af8c48f837da57000c068368d77bc9b06eba1e077edfab58df6aa2ea40ec
MD5 271e6a4d45c2817f86148ca413f97604
File Name mdm.exe
File Size 118784
First Seen 2014-05-20 08:43:15
C2 URL zipoo.redirectme[.]net
Resolution 196.45.144.12

Table 5

SHA256 e601da16f923b33465dbafbff9d47195e8fc50099fd0581a16a1745bf890afb6
MD5 be765cd5723e4366d35172aaf13fad44
File Name CitrixReceiverWeb.exe
File Size 135168
First Seen 2014-05-15 16:34:10
C2 URL zipoo.redirectme[.]net
Resolution 196.45.144.12

The malware dropped was configured to use good.myftp[.]org as the C2 URL, and the IP resolution was 223.25.233.248.  Both of these are known Nitro Indicators of Compromise (IOCs). In this case, the malware was a Farfli variant, again not a malware previously tied to this group. 39 AV vendors within VirusTotal properly identify the file as malware.  The PE timestamp on the file was 1 April, about two weeks before we saw the file. Continuing the activity, we discovered the actors had compromised a legitimate website belonging to an international technology company that provides Software Configuration and Change Management (SCCM) solutions in mid-May. (It is a well regarded company and partners with large companies such as Microsoft.)

Table 6

SHA256 184c083e839451c2ab0de7a89aa801dc0458e2bd1fe79e60f35c26d92a0dbf6a
MD5 ec519d709c0582346741fe0094208216
File Name update.exe
File Size 159744
First Seen 2014-04-15 01:13:14
C2 URL good.myftp[.]org
Resolution 223.25.233.248

The final sample, from mid-March, was also hosted on a compromised legitimate website, this time a small, US based IT company.  The IP resolved by the C2 URL was changed two days after we saw this file to overlap with good.myftp[.]org for a month before returning the below resolution. The filename matches that of the sample in Table 5, which had a very similar third level C2 domain and the same IP resolution. This is also a Spindest variant with a PE timestamp of the same day we saw it. 39 AV vendors within VirusTotal properly identify the file as malware.

Table 7

SHA256 ffbddfb536e8e604c880ec977d06f804a500fc0396899bd2c195fb1f5b74207a
MD5 a3b2e34973691ad320b70248bd67fbd2
File Name CitrixReceiverWeb.exe
File Size 192512
First Seen 2014-03-12 06:58:22
C2 URL zip.redirectme[.]net
Resolution 196.45.144.12

As this post and previous cited research show, APT groups such as Nitro will continue to evolve their techniques within the kill chain to avoid detection.  However, they also demonstrate the value of tracking these threats over time, as this allowed us to uncover and properly attribute the new IOCs because Nitro was still re-using old C2 infrastructure with their new malware.

For Palo Alto Networks customers, all of these files were properly identified by WildFire as malware and all of the C2 domains are labeled as threats in both Threat Prevention and URL Filtering systems.

[Source: Palo Alto Networks Research Center]

Posted on

5 Truths of HIPAA Security Risk Assessment

Risk assessment should serve as the foundation for any Health Insurance Portability and Accountability Act (HIPAA) security compliance effort, and for that matter, the cornerstone for the overall information security program. Consider these five truths to help grasp the criticality of the security risk assessment to achieving and demonstrating HIPAA compliance:

  1. It is not optional. All organizations deemed covered entities or business associates under HIPAA are required to perform an accurate, thorough and periodic risk assessment in to demonstrate compliance with the HIPAA Security Rule. No matter the level of security employed, an organization cannot be compliant without a documented risk assessment. The Security Rule requires entities to evaluate risks and vulnerabilities in their environments, and to implement reasonable and appropriate security measures to protect against anticipated threats or hazards to the security or integrity of electronic protected health information (e-PHI). Risk analysis is the first step in that process.
  2. It is not black and white. Risk analysis is generally a subjective undertaking, and there are a number of available risk frameworks that provide a methodical approach to complete a risk assessment. While the Office of Civil Rights has not outlined a prescriptive risk analysis framework, it has issued guidance that outlines essential elements of an acceptable risk assessment. In a nutshell, an organization must systematically identify and document: all electronic media touching e-PHI; all threats and vulnerabilities which could result in inappropriate access to or disclosure of the organization’s e-PHI; the implementation and effectiveness of security measures; and the determination of threat occurrence likelihood, impact, resulting risk level and risk mitigations.
  3. It is not easy. The Security Rule is comprehensive and inclusive of all e-PHI created, received, maintained or transmitted within the IT environment. A risk assessment cannot simply consist of a checklist, but must demonstrate the totality of systems inventoried in scope, e-PHI identified, and risk decisions. Also, the scope of the security risk assessment most often exceeds just electronic health records (EHR) application data, as it must cover all e-PHI maintained within other systems (consider legacy, shadow, and end-user systems).
  4. Documentation is key. All information considered, compiled and reviewed will form the basis for risk assessment and demonstrates the rationale for risk decisions. Documentation of data collection efforts, security controls evaluation, analytical procedures performed, and methodology for risk prioritization evidences a thorough and comprehensive risk assessment. Further, risk assessment documentation is a must if using control rationalization to demonstrate why an organization opts not to implement any HIPAA addressable controls.
  5. Build it into process. Organizations should continuously explore all areas of technology risk facing the business with an integrated risk analysis approach, including the implementation of new technologies and the ongoing management of central applications holding e-PHI. While an EHR application should have security controls embedded within, actual implementation of the EHR is critical, as is a secure integration into the overall IT infrastructure. It is imperative to consider security essentials, such as encryption and access controls, during design and implementation phases, and in subsequent changes and upgrades. An integrated risk analysis process enables the proactive identification of risks and facilitates timely risk management.

True risk assessment does not simply entail the completion of a compliance checklist that is locked away in a file cabinet until the auditor arrives. Comprehensive risk assessment must fully evaluate the relevant threats, vulnerabilities, risks and related controls over the security of all e-PHI, and all systems handling this sensitive data. Accurate risk assessment represents a worthy challenge to any organization, but done well, it pays dividends in the management of enterprise risk and demonstration of HIPAA compliance.

Gary Miller, CISA, CCSA, CIA, CISSP, CRMA, ITIL
Information Security Manager
Dell SecureWorks
gary_m@dell.com

Gary will discuss this concept at ISACA’s North America Information Security and Risk Management (North America ISRM)Conference this November, in his presentation titled, “HIPAA Security Risk Assessment.”

[Source: ISACA]

English
English
Exit mobile version