Random Thoughts, Security Learning, What you need to know?

Cloud Computing & Security – 101

Leave a comment

“Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources like networks, servers, storage, applications, and services that can be rapidly provisioned and released with minimal management effort or service provider interaction”.

Source: The NIST Definition of Cloud Computing, Version 15, 10-7-09, National Institute of Standards and Technology, Information Technology Laboratory

Cloud computing is the new mantra in most of the organizations but is Cloud computing new? Personally, I believe it has been there ever since Internet email has been available. Yahoo, Hotmail, AOL etc. in their heydays were a basic cloud computing model. However, the evolution of cloud computing has taken root only in the last few years what with storage becoming cheaper and Internet access exploding globally. Now they are able to support  Enterprise applications and business processes out of the cloud environment.

The lure of cloud computing and the benefits it brings is illustrated in the graphic below.

Cloud Computing

 Security Risks in Cloud Computing:

As with any new shift in computing methods, even Cloud computing has it’s share of risks. Some of the key risks of Cloud Computing are listed down below:

Risks Implications
Geography Given various countries and various regulatory authorities, controls for supporting appropriate cross border data views and use must be maintained
Defining ownership, custodianship, processing & use rights and obligations Clearly establish rights and obligations associated with data assets. Often rights and obligations are dependent on the physical location of the data owner, custodian and user. Designing and implementing effective controls to support appropriate rights and obligations may be complex
Multi-tenancy In a multi-tenant cloud environment,users may access shared resources, possibly gaining unauthorized access to other tenants. This may have less risk in a private cloud, but more risk in a public cloud
Security If one of the cloud servers get compromised, will it lead to compromise of the other servers in the shared infrastructure? Public cloud may have an increased attack surface compared to the private cloud, however, any compromise .
Data Loss On transient systems, a cloud vendor provider instance failure may lead to permanent loss of system information including system configuration and data stored locally. The concept of a “disposable” server also adds to the risk of loss of data and system information.

 

Tackling the Security Risks:

Based on the risks listed above, the various controls that can be considered in tackling them are listed below:

Privacy and data protection
  • Establishing Data ownership across organizational data
  • Managing access rights based on data classification
  • Implementing data storage and retention policies at the cloud vendor
Security incident response
  • Managing incident investigations in a virtualized environment
  • Limiting incident spill over to multiple cloud tenants
  • Handling complicated troubleshooting due to continuous
    environment changes or elasticity
Access control
  • Access controls for cloud management interfaces
  • Access controls for segregation of duties
  • Due diligence prior to assignment of access privileges
Vulnerability management
  • Managing virtualization induced vulnerabilities
  • Ensuring timely security patches
  • Adequate vulnerability testing of cloud components
Data Leakage or Loss
  • Ensuring adequate controls on transit systems to prevent data leakage
  • Adequate change control to migrate data when instance change happens
  • Security tools to detect & prevent such threats
Virtualization
  • Proper security controls over virtual servers and applications could stop multiple security incidents across the organization
  • Secure virtual storage could act as excellent risk control for reducing impact of storage compromises and data theft

 

Conclusion:

Cloud computing is here to stay and it is important that we understand the security risks and some potential controls that can be implemented when moving to cloud. This post is a primer to what Cloud computing is and what are the various security challenges presented by it.  Let me know your thoughts on this

Head 2 Head, Security Learning, Security Tools, SIEM, What you need to know?

Punching Hard – McAfee Nitro SIEM

12 Comments

intel-security-logo

At Infosecnirvana, we have quite a number of posts dedicated to SIEM. We have done a detailed comparison of SIEM products in a post titled – SIEM Comparison along with providing a detailed check list for SIEM evaluation.  We have also posted about SIEM products from time to time as reflected by our post on IBM QRadar and ArcSight. Following up with those posts, this blog is our take on McAfee Nitro SIEM.  So let’s get started

Introduction:

McAfee in 2011 purchased Nitro Security to enter into the SIEM space and subsequently were taken up by Intel. This period of 2011 actually saw a few things happen in the SIEM market space. This included HP buying ArcSight, IBM buying QRadar and McAfee buying Nitro etc. etc. Each of those SIEM products have taken a different route over the last 3 years. Nitro security was one of those niche players in the market which had an IPS portfolio as well a SIEM portfolio, remnants of which still linger in the overall McAfee ESM  product suite. The McAfee ESM product suite is basically a combination of a few components like:

  • ESM – Enterprise Security Management, which serves as the Management Interface for all SIEM components, Reporting engine capable of generating compliance and policy reports.
  • ACE – Advanced Correlation Engine which is interesting a dedicated engine to perform Risk Based (rules based) Correlation, Historical Correlation, Asset Based Risk Scoring and Custom risk scoring based on combinations of fields.
  • DBM – Database Monitor. One of the products McAfee has as standalone for Database Log Generation, Session Auditing etc, is called the DBM. This is a Database IPS kinda product that monitors network traffic via SPAN, port mirror or taps and does not create any impact on database. So for all the legacy databases that don’t have Audit trail enabled or the auditing is not detailed enough, DBM is the perfect fit. Apart from the monitoring audit trail of all transactions from login to log-off including all session queries and commands, it also provides Auto discovery of database instances including unauthorized or rouge databases. The DBM comes in both a network sensor as well as a host agent footprint.
  • ADM – Application Data Monitor. This is again a Application IPS kinda product capable of performing Layer 7 Protocol detection, Full meta-data collection, traffic monitoring via SPAN, port mirror or taps. Full session data capture and visibility into all application traffic is also provided by this sensor along with Advanced Threat detection capabilities. Again, it can be deployed as a sensor or a host agent.
  • ELM – Enterprise Log Manager. This is akin to any log management solution in SIEM and provides Log storage both Local and Network based.
  • Receivers – These are nothing but Parsers, Netflow Collectors, VMWare Collectors and anything that is able to parse and normalize logs.

Strong points for Nitro SIEM: 

After careful evaluation of Nitro SIEM, we would like to highlight these few points as the core Strength of Nitro SIEM:

  1. Architecture: One of the reasons for Nitro SIEM’s popularity is the Architectural flexibility. As a Security administrator, you can pick and chose how you want to architect your solution. If you want to be as modular as possible, then all the above mentioned components can be deployed standalone and integrated using the ESM (Remember EPO architecture for McAfee Endpoint solutions!!!). Say you prefer a smaller footprint, then you can build something called “Combo Boxes” which as the name mentions combines several components in a single box. This helps administrators starved of resources or budget to effectively deploy Nitro SIEM.
  2. Powerful Data Management: One of the biggest strengths of Nitro is the underlying Database – The SAGE DB aka NitroEDB (Nitro Embedded Database) developed by Idaho National labs (the founder of Nitro was a researcher there). NitroEDB is a relational database that supports huge volume, VLDB applications as well as extremely fast in-memory processing. This is the core reason why Nitro SIEM is able to have a High Ingest Rates and extremely fast query speed. This is a killer benefit compared to the other products like ArcSight with its below par implementation of MySQL and PostgreSQL and IBM QRadar with its proprietary EDB (updated based on comments from JC). Splunk is the closest in competition to Nitro with its GFS like implementation.
  3. High Ingest Rates: As mentioned above, NitroEDB enables SIEM to have a high event ingestion rates @ 300K EPS. We don’t think any SIEM in the market today scales up to this number. ArcSight SIEM is the closest with a 100K maximum with its Logger platform and a pure play Syslog-NG server can do 300K EPS.
  4. Network Based Threat Detection: As with QRadar Intelligence Platform, the Nitro platform also uses Network Packet Analysis for DBM and ADM (as mentioned in the components) to perform Database monitoring and Application monitoring. Both QRadar and Nitro are comparable in the Application monitoring space  but when it comes to Database Monitoring, Nitro wins it hands down. ArcSight and the others are poor in this space, something they will have to start looking at.
  5. Database Monitoring: As mentioned above, the DBM is the stand out as it provides excellent auditing capabilities for DB auditing and log collection. This is irrespective of DB version, OS, Auditing capability etc. The monitoring can be done off-box using a sensor in the network or using an agent. Again, this is one of the differentiators compared to ArcSight or QRadar as both of them rely only on JDBC connectivity to pull audit logs (provided Auditing is enabled on DB)
  6. Historical Correlation: Nitro has the ability to perform historical correlation better than the others in the market. One of the reasons for that is the capability to run complex queries and computations (for risk score correlation) against a large data set. This is primarily attributed to the NitroEDB as mentioned above which is really powerful in terms of query performance. QRadar and ArcSight are not as good at historical correlation and pale in comparison with NitroEDB performance for historical queries. Splunk is better at historical queries, but correlation is not as mature in Splunk as the others.
  7. SCADA Device Support: Apart from ArcSight, arguably the only other product in today’s market that has extensive support for SCADA is Nitro SIEM. This is definitely useful in penetrating the Utilities industry, Manufacturing industry etc. and is one of the key differentiators compared to the others.

Weak points for Nitro SIEM:

  1. Stability: In our testing and real-life deployments, one of the recurring problems we have faced with Nitro SIEM is stability. It is rare to have all the components working without issues at any given point in time. One of the reasons for this we think is the integration tier that has to interact with the various components to perform Security monitoring. There are just too many points of failure and troubleshooting is a nightmare. This is essential in organizations where in-house monitoring is performed. In case of outsourcing, even though this is still an issue, the risk is transferred to the outsourced vendor. Hopefully, McAfee realizes this and fixes these teething issues of stability in future releases.
  2. Correlation: Even though Risk based correlation is a great value add in Nitro, the overall capabilities fall short when compared with the others in the market. We might be a bit biased with this piece as we always compare Correlation capabilities of any SIEM we evaluate against HP ArcSight. In our opinion, ArcSight Correlation is by far the best in the industry and no product can match it in terms of flexibility, power of customization and advanced computing. That said, Nitro does compete hard and we would definitely be keen to see them take the Risk/Rules based correlation to the next level.
  3. Event Parsing & Custom Event Support: Even though the support for Events generated by Third Party vendors is excellent, we feel that more devices and vendors can be supported as does ArcSight. However, custom parsers or receivers are not intuitive to create in Nitro SIEM as with QRadar.  Nitro is not as good as the Super-Easy QRadar Custom Mapping feature or Splunk with its Field Extraction where it’s a breeze to develop any custom connector. Nitro, thus has some room for improvement in this area.
  4. User Interface: Although the UI reminds you of all things McAfee (EPO, NSM etc), we feel that a flash driven UI is not the best for SIEM. This is not to take away anything from the capabilities of the product in terms of data presentation, but Flash driven UI proves to be a dampener on the overall experience.  As a general opinion, we are keen to see anything other than a Java or Flash UI because we feel that both of them are the most vulnerable software out there and both are clunky when it comes to event analysis, visualization etc. This is where we feel QRadar has a refreshing interface. It does use Java for some parts of the console, but otherwise, the Browser console is so light and so simple that working with QRadar is a delight. Even Splunk has a wonderful UI and is really easy to use compared to ArcSight and Nitro which feel clunky and heavy.

Conclusion:

Overall, McAfee Nitro SIEM is a very good product that scales up against the Industry leaders – ArcSight and QRadar toe to toe. However, as with all acquisitions, they have a few chinks to work out before they truly are ready to lead the pack. Gartner ratings, if anything to go by, consistently rate McAfee in the leaders quadrant but they have been in the 3rd position for quite some time now. With HP ArcSight not doing anything new in the last two releases, QRadar is the only competitor to look forth and emulate. Hope McAfee rises above the competition with a more stable and mature SIEM product thereby shaking the Industry up.

So that’s it folks. Feel free to comment on what you feel about McAfee Nitro SIEM and what its benefits and weakness are.

Security Investigation Series

Episode 6 – ShellShock Investigation Part 2

1 Comment

Over the past few days, we have been researching about Shellshock and found a number of attack vectors that makes the vulnerability much easier to exploit. This article may not contain the entire list of attack vectors but we are doing our best in updating this list. Kindly leave us a comment if you have faced any attack vectors apart from what we are discussing here.

MOST COMMON VECTORS

The most commonly used vectors that can lead to exploiting this vulnerability are

  1. CGI
  2. SSH and
  3. DHCP

Apart from these commonly known attack vectors, we were able to find a list of other attack vectors, which aid in exploiting this vulnerability. We will discuss mainly the above-mentioned vectors and plunge into other less common vectors.

Shellshock is a vulnerability that allows hackers to inject commands to a computer’s operating system over the network. The vulnerability potentially affects most versions of the Linux and Unix operating systems, Mac OS X, Servers, Wi-Fi routers, Firewalls and even appliances, which invoke bash shell.

For a system to be vulnerable to Shellshock, the following 3 conditions must be met:

  1. It must set an environment variable whose value is attacker-controlled and must begin with “() } “
  2. It must invoke bash shell

3.The system must be running on a vulnerable version of bash.

Having a basic idea of Shellshock, let us begin our discussion first on the common attack vectors that are being employed.

1.Common Gateway Interface (CGI) which is an interface between a web server and executable that produce dynamic content and has been identified as the major attack vector.

Let us start our discussion with a typical HTTP request looks like the following:

GET /path?query-param-name=query-param-value HTTP/1.1
Host: www.example.com
Custom: custom-header-value

The CGI specification maps all parts to environment variables. With Apache httpd, the magic string “() {” can appear in these places:

* Host (“www.example.com”, as REMOTE_HOST)
* Header value (“custom-header-value”, as HTTP_CUSTOM in this example)
* Server protocol (“HTTP/1.1”, as SERVER_PROTOCOL)

The user name embedded in an Authorization header could be a vector as well, but the corresponding REMOTE_USER variable is only set if the user name corresponds to a known account according to the authentication configuration, and a configuration which accepts the magic string appears somewhat unlikely.

In addition, with other CGI implementations, the request method (“GET”), path (“/path”) and query string (“query-param-name=query-param-value”) may be vectors, and it is conceivable for “query-param-value” as well, and perhaps even “query-param-name”.

  1. Secure Shell (SSH) vector arises from the ForceCommand functionality, which allows a SSH server to be configured to restrict user actions. An authenticated malicious user could send a crafted communication that would trigger the BASH vulnerability, effectively allowing the attacker to break out of these restrictions and execute arbitrary commands. Since SSH is often used to tunnel and facilitate other services, applications that depend on this functionality may also be affected.
  1. DHCP clients can manipulate environment variables using data taken from DHCP server. If the DHCP client machine is running BASH, then the vulnerability will be triggered when it connects to a malicious DHCP server. This will often occur automatically, silently and with no user input. To make matters worse, DHCP clients have more privileges than CGI scripts. This affects the default DHCP clients found on most Linux flavors, but OSX is unaffected, as it uses a different implementation

We can start a DHCP server on the network and set the random string value to () { ;}; echo “This is a test”. We can replace the string to “This is a test” to any command that we want the client machine to execute.

Additional information can be grabbed from:

https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/

LESS COMMON VECTORS

As we have discussed the most common attack vectors of Shellshock vulnerability, we will also have an overview of the less common vectors that are being used to exploit the vulnerability.

MAIL SERVICES: Majority of the UNIX mail services are exposed to Shellshock vulnerability during their mail handling procedures. Exim, Postfix, qmail and Procmail are the mail services that can be used to exploit the vulnerability.

EXIM sets a number of attacker controlled environment variables when invoking the pipe transport. Whether or not it uses the shell invoke it is determined by the use_shell op­tion. Even if the use_shell is not set, the program invoked is often a shell script. Therefore, many Exim configurations are likely to be vulnerable.

Postfix does not set any attacker-controller environment variables, so Postfix is not typically vulnerable.

qmail can be used as an attack vector to exploit the bash vulnerability which can be used to execute arbitrary commands as any valid user with a .qmail containing a program delivery. The conditions that need to be met for exploiting the vulnerability using qmail are:

1) “Shellshock”-vulnerable bash

2) /bin/sh symlinked to bash

3) Email delivery via qmail to a valid user with a .qmail file containing ANY program delivery (the actual program being delivered to is irrelevant)

OPEN VPN can be configured to call out to a number of user-supplied helper programs. Open VPN does not itself use the shell invoke them, but the programs themselves are usually shell scripts. It sets a number of environment variables few of which, such as fields parsed out of the X.509 certificate, are possibly attacker-controlled. Servers can cause clients (but not vice versa) to set $foreign_option_* to arbitrary values. Many Open VPN configurations are likely to be vulnerable.

 

Achieve Nirvana in Information Security

Follow

Get every new post delivered to your Inbox

Join other followers: