Login  |  Register  |  Contact
Wednesday, June 30, 2010

Understanding and Selecting SIEM/LM: Advanced Features

By Adrian Lane

We’ve already discussed the basic features of a SIEM/Log Management platform, including collection, aggregation and normalization, correlation and alerting, reporting and forensics, and deployment architectures. But these posts cover the core functions, and are part of what each products in the space will bring to the table.

As markets evolve and vendors push to further differentiate themselves, more and more capabilities are integrated into the platforms. In the case of SIEM/LM, this means pumping more data into the analysis engine, and making engine smarter. The idea is to make 1+1 produce 5, as multiple data types provide more insight than a single source – that’s the concept, anyway. To be clear, having more data does not make directly the product any better. The only way to really leverage additional data is to build correlation rules and alerts and reports that utilize the extra data.

Let’s take a tour through some of the advanced data types you’ll see integrated into SIEM/LM platforms.

Flow

Network flow data is the connection records that stream out of a router or switch. These small and simple data files/streams typically list source, destination, and packet type. Flow data was really the first new data type which, when integrated with event and log data, really made the systems smarter. Flow data allowed the system to establish a baseline and scan for anomalous network traffic as the first indication of a problem.

An entire sub-market of network management – network behavioral analysis – revolves around analyzing and visualizing flow data to understand the traffic dynamics of networks, and pinpointing performance and capacity issues before they impact users. Many of the NBA vendors have been unsuccessfully trying to position their products in the security market; but in combination with events and logs, flow data is very useful.

As an example, consider a typical attack where a web server is compromised and then used as a pivot to further compromise an application server and the backend database server. The data needs to be exfiltrated in some way, so the attackers establish a secure pipe to an external zombie device. But the application server doesn’t typically send data to an external device, so flow data would show an anomalous traffic flow. At that point an administrator could analyze the logs, with correlated activity showing a new account created on the database server, and identifying the breach.

Could an accurate correlation rule have caught the reconnaissance and subsequent compromise of the servers? Maybe. But the network doesn’t lie, and at some point the attackers need to move the data. These types of strange network flows can be a great indicator of a successful attack, but remember strange flows only appear after the attack has occurred. So flow data is really for reacting faster to attacks already underway.

Even more powerful is the ability to set up compound correlation rules, which factor in specific events and flow scenarios. Of course setting up these rules is complicated and they require a lot of tuning, but once the additional data stream is in place, there are many options for how to leverage it.

Identity

Everyone wants to feel like more than just a number, but when talking about SIEM/Log Management, your IP address is pretty much who you are. You can detect many problems by just analyzing all traffic indiscriminately, but this tends to generate plenty of false positives. What about the scenario where the privileged user makes a change on a key server? Maybe they used a different device, which had a different IP address. This would show up as an unusual address for that action, and could trigger an alert.

But if the system were able to leverage identity information to know the same privileged user was making the change, all would be well, right? That’s the idea behind identity integration with SIEM/LM. Basically, the analysis engine pulls in directory information from the major directory stores (Active Directory & LDAP) to understand who is in the environment and what groups they belong to, which indicates what access rights they have. Other identity data – such as provisioning and authentication information – can be pulled in to enable advanced analysis, perhaps pinpointing a departed user accessing a key system.

The holy grail of identity integration is user activity monitoring. Yup, Big Brother lives – and he always knows exactly what you are doing. In this scenario you’d be able to set up a baseline for a group of users (such as Accounting Clerks), including which systems they access, who they communicate with, and what they do. There are actually a handful of other attributes that help identify a single user even when using generic service accounts. Then you can look for anomalies, such as an accounting clerk accessing the HR system, making a change on a sensitive server, or even sending data to his/her Gmail account. This isn’t a smoking gun, per se, but it does give administrators a place to look for issues.

Again, additional data types beyond plain event logs can effectively make the system smarter and streamline problem identification.

Database Activity Monitoring

Recently SIEM/LM platforms have been integrating Database Activity Monitoring (DAM), which collects very detailed information about what is happening to critical data stores. As with the flow data discussed above, DAM can serve up activity and audit data for SIEM. These sources not only provide more data, but add additional context for analysis, helping with both correlation and forensic analysis. Securosis has published plenty of information on DAM, which you can check out in our research library.

The purpose of DAM integration is to drive analysis deeper into database transactions, gaining the ability to detect patterns which indicate successful compromise or misuse. As a simple example, if a mobile user gets infected at Starbucks (like that ever happens!) and then unwittingly provides access to the corporate network, the attacker then proceeds to compromise the database.

The DAM device monitors the transactions to and from the database, and should see the attack traffic. At that point the admin must go to another system to figure out the issue with the rogue device. But if all the data is available within a single platform, the admin would be able to instantly know about the compromised device and remediate.

Additionally, powerful correlation rules can be set up to look for account changes and other significant events on certain servers, followed up by a data dump from the database (recorded by DAM), and a bulk file transfer to an external location (detectable in flow data). This is certainly getting closer to a smoking gun, if the attack scenarios are modeled and implemented as rules in the SIEM/LM.

Application Monitoring

Like DAM, some SIEM/LM platforms are climbing up to the application layer by ingesting application logs, as well as performing simple content analysis on specific application types – typically email or web traffic. Again, baseline models can identify how applications should behave; then alerts can be set up for behavior which is not normal.

The problem with application monitoring is the amount of work required to get it right. Each application works differently in each environment, so significant tuning is required to get the rules right and tighten thresholds enough to provide relevant alerts. With the number of application in a typical organization, getting useful coverage within an environment takes substantial time and resources.

But over time this capability will continue to improve and become much more useful in practice. We expect that to take another 12-18 months.

Configuration Monitoring

Another data type useful for SIEM/LM integration is configuration data. This means many different things to different folks, so let’s level set a bit. We are referring to the configuration settings for security, applications, network, and computing devices. Most attacks involve some type of configuration change, whether it’s a service turned on or off, a new user added, a new protocol allowed, or a destination address added. Monitoring for these changes can again provide key hints to an attack in progress.

This integration can happen with the SIEM/LM platform directly collecting and monitoring the configurations (many of the vendors can monitor network and security device configurations) or by taking an alert or log stream from a standalone configuration monitoring product. Either way works, so long as the correlation rules and reports are built to take advantage of the configuration data.

Let’s run through a quick scenario. In the event of an attack on a retailer’s POS system, events would show reconnaissance activity on a store wireless network, which happens frequently and so shouldn’t trigger any alarms. The attacker than breaks the WEP key and gains access to the POS network, then compromising the POS devices, which run on an un-patched version of embedded Windows XP. Yes, I know this organization deserves to be pwned for using WEP and unpatched XP, but indulge me a bit. None of this would necessarily be caught through typical event logs.

But then the attacker enable FTP on the POS terminal, which would change the configuration and be detected by configuration monitoring. So the admin can investigate FTP being active on a POS device, which indicates badness. Combine that with other event and logging activity, and a case for further investigation can be made – which is the point of having the SIEM/LM platform in the first place.

File Integrity Monitoring

The last data type we’ll discuss is file integrity data. This involves monitoring for changes on key system files such as the IP stack. If one of these files changes (and it’s not traceable to a legitimate patching), it usually indicates some kind of unauthorized activity. So this data is similarly useful for helping to narrow the scope of analysis for a security analyst.

If the analyst sees system files changing on a critical server, in combination with strange network flows, other configuration changes, and IDS alerts, that’s a good indication of a successful attack. Remember, it isn’t necessary to find a smoking gun. SIEM/LM is useful if it can make us a bit smarter and enable a security analyst to react faster to an attack.

Direct or Indirect Integration?

One of the ways vendors try to differentiate is by whether their product takes the data in directly and does the analysis within the SIEM/LM platform, or partners with leading vendors of standalone solutions – such as NBA or configuration monitoring. We aren’t religious one way or the other.

There are advantages to direct integration – all the data is in one location, which facilitates forensic investigation; this may also enable more detailed correlation rules and compliance reports. On the other hand, a standalone NBA system is more useful to the network administrator, at the expense of fewer capabilities built into the SIEM. If it’s the network administrator’s budget they will buy NBA, and the security team will get alerts. Either way is fine, since it’s about making the SIEM/LM smarter and focusing investigations.

Additional Data = More Complexity

As we described in the series introduction, making SIEM/LM work is a fairly complicated endeavor, and that’s just dealing with logs and events. When you add a couple or more additional data types, you multiply the number of rules and reports the system can generate. Couple that with enrichment and activity profiles, and you have seriously increased complexity. That can be positive (by supporting broader analysis) as well as negative (because tuning and performance become bigger issues), so be careful what you wish for.

Ultimately, the use cases need to drive the advanced features needed during the procurement process. If you are just trying to meet a compliance automation requirement, then flow data may not be that useful and shouldn’t weigh heavily in the vendor analysis. But if you are trying to gain operational efficiencies, then something like configuration monitoring should allow your analysts to kill both birds with the same platform, so the data type becomes more important.

—Adrian Lane

Incite 6/30/2010: Embrace Individuality

By Mike Rothman

I still go see a lot of live music. Yes, it’s a luxury, but I’d rather give something else up than my handful (OK, maybe two handfuls) of shows every year. On Monday night we saw Sting with his big orchestra. It was definitely a more mellow show than when we saw him a few years ago with his band (right, The Police), but it was a good show nonetheless.

We are all individuals -- to a point. I usually go to shows with the Boss and we each have different things that we like and don’t like about live music. Over the past few years we’ve learned to accept each other’s show angst. She likes to sit close and sometimes when the budget and availability work out, we get decent seats.

In the event we don’t get close, she’s usually looking for an opportunity to move up. That gives me angst. Bordering on paranoia. When I’m in someone else’s seat I’m figuring each person who walks by wants their seats back and will probably hit me with a bat. I know, it’s not logical, but it causes me angst. It kills my proverbial show buzz.

The Boss has no irrational seat squatting fear, so she just waits to be ejected and is cool with that. But she’s got show issues too. It makes her nuts when someone around us is talking. I mean nuts. I should call her Ms. Shush. Since she’ll usually just tell them to uh, quiet down. She does have a point in that these people pay a hundred bucks to go to a show and then talk about their goiters or sports teams or some asshat at work. Go figure. But the extraneous noise doesn’t bother me. I focus on the performer and tune everything else out.

I could get annoyed that she’ll disappear for most of a show and meet me later if she gets a better seat. And she could get annoyed that the chatter doesn’t bother me. But that’s not productive. Now we know each other’s angsts and we accommodate. I let her go walkabout and if she does stay in our seats, I’ve become a burgeoning Mr. Shush because I know her experience is better if everyone shuts their traps.

And it works for us. But only if you embrace your partner’s individuality and learn to roll with it. Maybe I have learned something after 13+ years of marriage.

– Mike.

Photo credits: “Individuality Redux” originally uploaded by spaceamoeba


Recent Securosis Posts

  1. Friday Summary: June 25, 2010
  2. Understanding and Selecting a Tokenization Solution: Introduction
  3. Are Secure Web Apps Possible?
  4. NSO Quant: Manage Firewall Process Map
  5. NSO Quant: Manage IDS/IPS Process Map
  6. Adrian and Rich are wrapping up DB Quant

Incite 4 U

  1. Toothless FTC ‘Settles’ with Twitter – So it seems Twitter got a slap on the wrist recently from the Federal Trade Commission for misleading consumers about protecting their privacy. The Twitter folks settled to make the problem go away, which was the right thing to do. Twitter is now barred for 20 years “from misleading consumers about the extent to which it maintains and protects the security, privacy, and confidentiality of nonpublic consumer information.” That’s a relief. And they need to be subjected to a security program review every other year for 10 years. Again, what major service provider doesn’t do this? In the article it does talk about some stuff that Twitter was (or wasn’t) doing, which are good practices. Like requiring strong admin passwords and not allowing administrators to store those passwords in their personal email. Duh. Anyhow, the FTC getting involved is fine, but if they want organizations to be more serious about privacy, they need more impactful consequences. – MR

  2. Assured Integrity on Bogus Data – Richard Bejtlich’s post on Dealing with Security Instrumentation Failures, along with the referenced articles on Si(EM)lent Witness hits on a trifecta of weaknesses in security monitoring devices at large: dropped or missing events, capturing only one side of a conversation, and touting the integrity of an already suspect data stream. In everything from IDS to DAM, dropped transactions are a real problem. Network monitoring that captures a request but fails to capture the response is a real problem. Both receive hand-waves from vendors and surprisingly from security practitioners as well, who assume the other 98% of events is enough. But have they quantified the loss, or the percentage of records that are missing? The percentage that are missing a portion of the data? Examine carefully the claims of SIEM, DAM, and other event storage vendors that the data is totally secure – privacy and integrity are typically 100% assured. But the stream before it arrives at its destination? Suspect! I used to play the injection game, throwing garbage statements on the wire that were completely ignored by the application, but picked up by the monitor because it had the right IP and port. Since they failed to collect response codes, this counted as legit traffic. I am not saying that you can necessarily do anything about it, but give it some thought, and have some test cases to verify how your tools handle them, or what the packet loss expectancy really is. – AL

  3. A Different Kind of Disclosure – We all know the disclosure debate will never end. It’s basically religion on all sides; with few willing to change their positions and little more than anecdotal evidence available, you can spin it however you want. But I think we can all agree that no one wants to find out about a vulnerability like WellPoint did. A customer figured out she could see others’ records by manipulating the URL (yes, about the most basic vulnerability a web application can have). Instead of reporting it to WellPoint she called her lawyer. WellPoint found out they were vulnerable when she sued them for breach of privacy. Then again, it seems the exposure may have mostly been limited to her and her lawyers poking around. WellPoint fixed the problem in 12 hours, and I’ll be curious to see whether they counter-sue or pursue criminal charges. Or whether the FBI busts in and arrests her on drug charges. – RM

  4. The Location Middle Ground – Although I have embraced some social networking stuff, I still consider myself a Luddite, and I’m OK with that. When I was recently at my college reunion, a friend was all into FourSquare, broadcasting his whereabouts to the Interwebs. I don’t get it. First off, I don’t want anyone to know where I am at any given time – it’s my business if I want to work at a Starbuck’s or a park or my home office. But for some aspects of location, I’m not sure how we lived before mobile phones and GPS. I mean, how else would you figure out where the closest Baja Fresh is in a new city? But privacy is still a major exposure, as pointed out in a recent NetworkWorld post. How are these companies using that data? And what’s to stop someone from extracting a crapload of stuff from FourSquare or Google or anywhere else, which could be used for who knows what? So as opposed to most 20-somethings today, who don’t seem to care about privacy, I’ll keep my location to myself, thank you very much. – MR

  5. A Small Exhaust Port, Just above the Main Port – A few years ago I gave a presentation on Web 2.0 (whatever that means) security. One of the issues I highlighted was inclusion of third party code/functionality. You may not realize it, but I’d say 99.999% of you have some sort of external code running through your site; anything from Google Analytics to advanced JavaScript libraries hosted elsewhere. I know this because I block a heck of a lot of it using various browser plugins. This inclusion is a very common practice, but means you are funneling someone else’s programming right to your customers via your site. One thing I hadn’t thought about for that presentation is that when you perform a vulnerability assessment against your own site, the odds are you can’t really scan the embedded code, since it’s running someplace else that might consider your scan an attack. WhiteHat Security ran into this problem even though they are vulnerability assessment experts. Jeremiah does an amazing job of disclosing their (minor) security foible, why it happened, and the limits of assessing external code. For the record, that’s one reason we try and host everything on our site, mirroring the code locally. – RM

  6. Dealing with the New Workforce – Our job as security professionals is to make sure the sensitive data within our organizations remains safe without adversely impacting how business operates (too much). But we can certainly get to the point of being a bit aggressive in our recommendations. I’m with the Imperva folks, as they point out some good recommendations from SecureWorks about protecting financial transactions against attacks like the Zeus Trojan, but I agree that others – like using a dedicated machine/VM for online banking – just won’t happen much because they’re too much of a hassle. But that’s not my point here – it’s that our workforce is changing and that means our protection strategies must change too. As a recent survey from Cisco shows, our new recruits are likely to work around our security controls, and will leave if we don’t let them do what they want. It’s not good or bad, it just is. So the idea of traditional command and control is out the window. Instead we focus on reacting faster/better and containing the damage, and grumble about how those crazy kids are screwing everything up. – MR

  7. Killing Innovation, One Startup at a Time – I spent a weekend earlier in the year ripping most of my CDs into iTunes. With Apple Lossless encoding it took about 170gb of space. I realized then that when I buy a Mac mini to become a music server, I will need to move all that content over. I was thinking about how cool it would be if I could just put the library in Dropbox and share it to any device. It appears that someone else had the idea, as mSpot is offering a service to do half of it. For me that would mean some $28.00 a month(!!!) just to store my own music. Plus it only supports one device, and I have 3 computers and four devices I want to use. I started thinking about the security aspects when I read the bottom of their press release: “The Recording Industry Association of America calls cloud-based music servers ‘an exciting development in the market place’”. Yeah, provided they can make money and not worry about security. What happens when people XSS their site and start grabbing other libraries? How exciting will it be when not just a single CD is stolen, but a huge music library? Odds are that if mSpot’s pricing and service model don’t kill them, the RIAA will, as soon as they get hacked. – AL

  8. As Things Move Faster, Standards Slow down – Last week, the PCI Security Standards Council announced they were changing the standards timeline (PDF), basically lengthening the time between updates to the PCI-DSS from two years to three years. That’s a relief, since we all know the rate of technology adoption and emergence of new attack vectors is slowing down accordingly. Not. The logical part of my brain understands that many retailers have lots of stores and it’s hard to change things quickly enough to even keep up with the current two year cycle. Then the pragmatic part remembers that my credit card number has been compromised at least 3 times that I know about (involving new card issuance), and I lose my empathy for the ‘poor’ retailers. Actually the truth is somewhere in the middle – the DSS is pretty stable at this point and shops adhering to the 12 requirements are in decent shape. Yes, they can get pwned, but that goes for anyone. And this gives us another opportunity to stress the fact that any standard/guidance/regulation is going to the lowest common denominator for your security posture. If you think you are done once you get the stamp, you are sorely mistaken. – MR

—Mike Rothman

Tuesday, June 29, 2010

Understanding and Selecting SIEM/LM: Data Management

By Adrian Lane

We covered SIEM and Log Management deployment architectures in depth to underscore how different models are used to deal with scalability and data management issues. In some cases these deployment choices are driven by the underlying data handling mechanism within the product. In other words each platform stores and manages data differently – these decisions have significant impact on product scalability, data management, and reporting & forensics capabilities. Here we discuss the different internal data storage models, with advantages and disadvantages of each.

Relational Database

In the early days of this technology, most SIEM and log management systems were built on relational database engines to store events and log records. In this model the SIEM platform maps data attributes from each data source into database columns, so each event is stored in a single database row. There are numerous advantages to this model, including:

  • Data Validation – As data is inserted into the column, the database verifies data type and range settings. Integrity check failures indicate corrupted files and are omitted from the import, with notification to administrators.
  • Event Consistency – An event from a Cisco router now looks just like an event from a Juniper router, and vice-versa, as events are normalized before being stored in the table.
  • Reporting – Reports are easier to generate from validated data columns, and the database can format data when generating the report. Reports run far faster thanks to column indices, effectively filtering and ordering events.
  • Analytics – An RDBMS facilitates complex queries across all available attributes, inspected content, and correlation.

This model for data storage has fallen out of favor due to the overhead of data insertion: as each row is inserted the database must perform the checks and periodically rebuild indices. As daily event volumes scaled from millions to hundreds of millions and billions, this overhead became problematic and resulted in significant scalability issues with SIEM offerings built on RDBMS.

Further, data that does not fit into the tables defined in the relational model is typically left out. Unless there is some other method to maintain the fidelity and integrity of the original event records, this is problematic for forensics. This “selective memory” can also result in data accuracy issues, as truncated records may not correlate properly and can hamper analysis.

As a result SIEM/LM architectures based on RDBMS are waning, as products in this space re-architect their backend data stores to address these issues. On the other hand, RDBMS storage is not totally dead – some vendors have instead chosen to streamline data insertion, basically by turning off some RDBMS checks and integrity verification. Others use an RDBMS to supplement a flat file architecture (described below), leveraging the advantages above for reporting and forensics.

Flat File

Flat files, or just ‘files’, are now the most common way to store events for SIEM and Log Management. Files are serve as a blank canvas for the vendor; as they can introduce any structure they choose to help define, format, and delineate events. Anything that helps with correlation and speeds up future searches is included, and each vendor has their own secret sauce for building files. Each file typically contains a day’s events, possibly from a single source, with each event clearly delineated. The files (in some cases each event) can be tagged with additional information – this is called “log enrichment”. These tags offer some of the contextual benefits of a relational database, and help to define attributes. Some even include a control structure similar to VSAM files. The events may be stored in their raw form, or be normalized prior to insertion. Flat files offer several advantages.

  • Performance – Since normalization (to the degree necessary) happens before data insertion, there is very little work to be performed prior to insertion compared to a relational database. Data is stored as quickly as the physical media can handle, and often available immediately for searching and analysis.
  • Flexibility – Stored events are not limited to specific normalized columns as they are in a relational database, but can take any form. Changes to internal file formats are much easier.
  • Search – Searches can be performed without understanding the underlying structures, using simple keyword search. At least one log management vendor provides a Google-style search capability across data files. Alternately, search can rely upon tags and keywords established by the vendor.

The flat file tradeoffs are twofold. First, any data management capabilities – such as indexing and data integrity – must be built from scratch by the vendor, since no RDBMS capabilities are provided by the underlying platform. This means the SIEM/LM vendor must provide any needed facilities for data integrity, normalization, filtering, and indexing. Second, there is an efficiency tradeoff. Some vendors tag, index, and normalize prior to insertion; others initially record raw events, later re-reading the data in order to normalize it, and then rewrite the reformatted data. The later method offers faster insertion, at the expense of greater total storage and processing requirements.

The good news is that a few years ago most vendors saw the scalability wall of RDBMS approaching, and began investing in their own back-end data management environments. At this point many platforms feature purpose-built high-performance data stores, and we believe this will be the underlying architecture for these products moving forward.

Of course, we don’t live in an either/or world, so many of the platforms combine some RDBMS capabilities with flat file aspects. Yes, the answer can be ‘both’.

—Adrian Lane

Friday, June 25, 2010

DB Quant: Manage Metrics, Part 3, Change Management

By Rich

Believe it or not, we are down to our final metrics post! We’re going to close things out today with change management – something that isn’t specific to security, but comes with security implications.

Our change management process is:

  1. Monitor
  2. Schedule and Prepare
  3. Alter
  4. Verify
  5. Document

Monitor

Variable Notes
Time to gather change requests
Time to evaluate each change request for security implications

Schedule and Prepare

Variable Notes
Time to map request to specific actions/scripts
Time to update change management system
Time to schedule downtime/maintenance window and communicate

Alter

Variable Notes
Time to implement change request

Verify

Variable Notes
Time to test and verify changes

Document

Variable Notes
Time to document changes
Time to archive scripts or backups

Other Posts in Project Quant for Database Security

  1. An Open Metrics Model for Database Security: Project Quant for Databases
  2. Database Security: Process Framework
  3. Database Security: Planning
  4. Database Security: Planning, Part 2
  5. Database Security: Discover and Assess Databases, Apps, Data
  6. Database Security: Patch
  7. Database Security: Configure
  8. Database Security: Restrict Access
  9. Database Security: Shield
  10. Database Security: Database Activity Monitoring
  11. Database Security: Audit
  12. Database Security: Database Activity Blocking
  13. Database Security: Encryption
  14. Database Security: Data Masking
  15. Database Security: Web App Firewalls
  16. Database Security: Configuration Management
  17. Database Security: Patch Management
  18. Database Security: Change Management
  19. DB Quant: Planning Metrics, Part 1
  20. DB Quant: Planning Metrics, Part 2
  21. DB Quant: Planning Metrics, Part 3
  22. DB Quant: Planning Metrics, Part 4
  23. DB Quant: Discovery Metrics, Part 1, Enumerate Databases
  24. DB Quant: Discovery Metrics, Part 2, Identify Apps
  25. DB Quant: Discovery Metrics, Part 3, Config and Vulnerability Assessment
  26. DB Quant: Discovery Metrics, Part 4, Access and Authorization
  27. DB Quant: Secure Metrics, Part 1, Patch
  28. DB Quant: Secure Metrics, Part 2, Configure
  29. DB Quant: Secure Metrics, Part 3, Restrict Access
  30. DB Quant: Monitoring Metrics: Part 1, Database Activity Monitoring
  31. DB Quant: Monitoring Metrics, Part 2, Audit
  32. DB Quant: Protect Metrics, Part 1, DAM Blocking
  33. DB Quant: Protect Metrics, Part 2, Encryption
  34. DB Quant: Protect Metrics, Part 3, Masking
  35. DB Quant: Protect Metrics, Part 4, WAF

—Rich

DB Quant: Manage Metrics, Part 2, Patch Management

By Adrian Lane

Continuing with management process metrics, we move into Patch Management. The specified process is sufficiently granular that we do not need to break these steps apart to capture the appropriate metrics as we have done with previous tasks. The vast majority of metrics will be amounts of time, with only sunk costs needed for database licensing or maintenance fees to acquire the patch and associated documentation.

<

div class=”bodyTable”>

Patch Management

Variable Notes
Monitor: Time to monitor for patch releases/advisories i.e. sift through patch release notices to identify what you need
Acquire: Time to obtain patch and documentation Optional costs for vendor support/maintenance
Evaluate: Time to perform initial ‘paper’ evaluation i.e. How does this affect the database? Are workarounds advisable?
Prioritize & Schedule: Time to coordinate resources for testing and deployment Include people and machines needed, with relative priorities
Test & Certify: Time to perform tests
Optional: Cost of test servers
i.e. verify patch fixed what it was supposed to and did not break anything else
Create Deployment Package: Time to package certified version i.e. Pull together certified patch revisions, documents and config changes
Deploy: Time to install the patch
Confirm Deployment: Time to verify patches were deployed Verify patches installed without error. Run sanity checks on database functions
Clean up: Time to clean up failed installs; time to clean up temp files i.e. remove temp files, failed installs, uncertified patches, logs, etc.
Document: Time to document changes Record changes, archive certified patch bundle, update internal revisions guide

Other Posts in Project Quant for Database Security

  1. An Open Metrics Model for Database Security: Project Quant for Databases
  2. Database Security: Process Framework
  3. Database Security: Planning
  4. Database Security: Planning, Part 2
  5. Database Security: Discover and Assess Databases, Apps, Data
  6. Database Security: Patch
  7. Database Security: Configure
  8. Database Security: Restrict Access
  9. Database Security: Shield
  10. Database Security: Database Activity Monitoring
  11. Database Security: Audit
  12. Database Security: Database Activity Blocking
  13. Database Security: Encryption
  14. Database Security: Data Masking
  15. Database Security: Web App Firewalls
  16. Database Security: Configuration Management
  17. Database Security: Patch Management
  18. Database Security: Change Management
  19. DB Quant: Planning Metrics, Part 1
  20. DB Quant: Planning Metrics, Part 2
  21. DB Quant: Planning Metrics, Part 3
  22. DB Quant: Planning Metrics, Part 4
  23. DB Quant: Discovery Metrics, Part 1, Enumerate Databases
  24. DB Quant: Discovery Metrics, Part 2, Identify Apps
  25. DB Quant: Discovery Metrics, Part 3, Config and Vulnerability Assessment
  26. DB Quant: Discovery Metrics, Part 4, Access and Authorization
  27. DB Quant: Secure Metrics, Part 1, Patch
  28. DB Quant: Secure Metrics, Part 2, Configure
  29. DB Quant: Secure Metrics, Part 3, Restrict Access
  30. DB Quant: Monitoring Metrics: Part 1, Database Activity Monitoring
  31. DB Quant: Monitoring Metrics, Part 2, Audit
  32. DB Quant: Protect Metrics, Part 1, DAM Blocking
  33. DB Quant: Protect Metrics, Part 2, Encryption
  34. DB Quant: Protect Metrics, Part 3, Masking
  35. DB Quant: Protect Metrics, Part 4, WAF
  36. DB Quant: Manage Metrics, Part 1, Configuration Management

—Adrian Lane

Friday Summary: June 25, 2010

By Adrian Lane

Thursday was totally shot. I wasted the entire day standing around. Eight hours and twenty nine minutes standing in line. I got in line at 5:50 AM and did not get back in my car until 3:00.

Yep, it was Apple iPhone day. And I did not have a reservation.

If you like people-watching, this is about as much fun as you will ever have. There were some 700 people at the mall by 6:30 AM. Close to me in line were two women with infants, and they were there all day. There were small children with their grandparents. The guy next to me had a shattered foot from a recent car accident. There were people calling their bosses, not to call in sick, but to tell them they were taking the day off to buy iPhones. These people were freakin’ dedicated.

I have not stood in line for any length of time since 1983, trying to get a good seat for Return of the Jedi. I have not stood in line without knowing whether I would get what I was there for since the Tutankhamun exhibit in, what, 1979? This is not something I do, but I wanted the phone. And actually I did not want the ‘phone’, but everything else. I wanted a (mostly) secure way to get email on the road. I wanted a mobile device to surf the web. I wanted a way to find Thai food. I wanted a better camera. I wanted a way to get directions when traveling. I wanted to have music with me. I wanted to access files in Dropbox whenever and wherever. And the BlackBerry did none of these thing well, if at all. Plus, as a device, the BlackBerry is a poorly-engineered turd in comparison. I was just done with it, and I wanted the iPhone, and I wanted it before Black Hat.

So there I stood, for eight and a half hours, holding a place in line for a guy with a broken foot so he could sit on the mall couch.

I have to say the Apple employees were great. Every 30 minutes they brought us water and Starbucks coffee. Every 15 minutes they brought snacks. They sent employees into the line to chat. They brought sample phones and sat with us, in line, to demo the differences. They thanked us for sticking it out. They asked us if we needed anything, holding places in line and bringing food. They took care of every part of the transaction, including dealing with AT&T and their inability to process credit cards without dialing up Equifax. Great products and great service … it’s like I was transported back in time to an age when those things mattered.

All in all I am glad I waited it out and got my phone. Camera is amazing. Display is crystal-clear. The phone does not have the hideous ‘pops’ in audio that blow my ears out, or randomly shut off for 20 seconds like the BlackBerry. And the FaceTime feature works really well, for what it’s worth. Would I do it again? Would I stand there for 8.5 hours? Ask me in another 25 years.

On to the Summary:

Webcasts, Podcasts, Outside Writing, and Conferences

Favorite Securosis Posts

Other Securosis Posts

Favorite Outside Posts

Project Quant Posts

Research Reports and Presentations

Top News and Posts

Blog Comment of the Week

Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. I was going to call Mike out for having male menopause, bu this week’s best comment goes to LonerVamp for taking the high road in response to Security Incite: Competitive Fire.

@Mike: Amen! Play the game the makes you happy and you win. Who knows, maybe for some of those guys it’s no win, no booty!

RE: Cyber-insurance: Yikes. What if the PCI Council offered insurance. They’d say something like, meet these checklist requirements. If you meet these requirements and get hacked, we’ll pay you out. If you say you meet these requirements, but get hacked due to not truly meeting these requirements, you don’t get paid out. The problem is this leads down the road of the PCI Council being your consultants and managed services provider, because you need to be meeting those requirements constantly. Not just during the audit week. It doesn’t help that few orgs know what data they even have let alone know what they’re doing to protect it appropriately. Cyber-insurance stills feels about as useful as Lifelock, to me.

—Adrian Lane

Thursday, June 24, 2010

Are Secure Web Apps Possible?

By Mike Rothman

We security folks are a tough crowd, and we have trouble understanding why stuff that is obvious to us isn’t so obvious to everyone else. We wonder why app developers can’t understand how to develop a secure application. Why can’t they grok SDL or run a damn scanner against the application before it goes live? Q/A? Ha. Obviously that’s for losers. And those sentiments aren’t totally misplaced. There is a tremendous amount of apathy regarding software security, and the incentives for developers to do it right just aren’t there.

But it’s not all the developers fault, because for the most part secure coding is a dream. Yeah, maybe that’s harsh and I’m sure the tool vendors will be hanging me in effigy soon enough, but that’s how it seems to me. Says the guy who hasn’t developed real code for 18+ years and leaves the application security research to folks (like Adrian) who are qualified to have an opinion. But not being qualified never stopped me from having an opinion before.

I come to this conclusion after spending some time trying to digest a post by Errata Security’s Rob Graham on the AT&T iPad hack. Rob goes through quite a few application security no-nos, quoting chapter and verse, pointing them out in this rather simple attack.

This specific attack vector doesn’t appear in the OWASP Top 10 list, nor should it. But it underscores the difficulty of really securing an application and the need to not just run a scanner against the code, but to really exercise the business logic before turning the app loose on the world.

Rob’s post talks about information leakage, security via obscurity, the blurring line between internal and external, and other ways to make an application do unintended things, usually ending in some kind of successful attack.

So does that mean we give up, which seemed to be one of the messages from the Gartner show this week (hat tip to Ed at Securitycurve)? Not so much, but we have to continue aggressively managing expectations. If you have smart guys like Rob, RSnake, or Jeremiah beat the crap out of your application, they will find problems. Then you’ll have an opportunity to fix them before the launch. In a perfect world, this is exactly what you would do, but it certainly isn’t the cheapest or fastest option.

On the other hand, you can run a scanner against the code and eliminate much of the lowest-hanging fruit that the script kiddies would target. That’s certainly an option, but the key to this approach is to make sure everyone knows a talented attacker specifically targeting your stuff will win. So when an attack not explicitly mentioned in your threat model (like the AT&T/iPad attack) happens, you will have to deal with it. And if you have some buddies in the FBI, maybe you can even get the hacker arrested on drug charges…

Or you could do nothing like most of the world, and seem surprised when a 12-year-old in Estonia sells your customers on a grey-market website.

To think we can really develop secure web applications is probably a pipe dream – depending on our definition of ‘secure’, obviously. But we certainly can make our apps more secure and outrun our slower competitors, if not the bear. Most of the time that’s enough.

—Mike Rothman

Wednesday, June 23, 2010

DB Quant: Manage Metrics, Part 1, Configuration Management

By Rich

We are finally entering the last phase of the database security process – Manage. Now we switch our focus from assessment and installation of security controls to ongoing management – keeping our systems up to date, properly configured, and (relatively) free from known vulnerabilities.

Our configuration management process is:

  1. Plan
  2. Assess
  3. Mitigate
  4. Verify
  5. Document

We changed “Control” from our initial post to “Mitigate”.

Plan

Variable Notes
Time to map database to configuration standard Developed in the Planning phase
Time to determine, approve, and document exceptions to the standard Individual databases may need exceptions to general standards

Assess

Variable Notes
Time to assess configuration This is the ongoing process of assessing the configuration, which should be run on a schedule, as opposed to the assessment run in the Discovery phase. Note that if you already have an ongoing discovery process, that covers this step.

Mitigate

Variable Notes
Time to adjust the configuration of the system to address violations

Verify

Variable Notes
Time to re-test and validate configuration updates

Document

Variable Notes
Time to document changes
Time to update baseline settings

Other Posts in Project Quant for Database Security

  1. An Open Metrics Model for Database Security: Project Quant for Databases
  2. Database Security: Process Framework
  3. Database Security: Planning
  4. Database Security: Planning, Part 2
  5. Database Security: Discover and Assess Databases, Apps, Data
  6. Database Security: Patch
  7. Database Security: Configure
  8. Database Security: Restrict Access
  9. Database Security: Shield
  10. Database Security: Database Activity Monitoring
  11. Database Security: Audit
  12. Database Security: Database Activity Blocking
  13. Database Security: Encryption
  14. Database Security: Data Masking
  15. Database Security: Web App Firewalls
  16. Database Security: Configuration Management
  17. Database Security: Patch Management
  18. Database Security: Change Management
  19. DB Quant: Planning Metrics, Part 1
  20. DB Quant: Planning Metrics, Part 2
  21. DB Quant: Planning Metrics, Part 3
  22. DB Quant: Planning Metrics, Part 4
  23. DB Quant: Discovery Metrics, Part 1, Enumerate Databases
  24. DB Quant: Discovery Metrics, Part 2, Identify Apps
  25. DB Quant: Discovery Metrics, Part 3, Config and Vulnerability Assessment
  26. DB Quant: Discovery Metrics, Part 4, Access and Authorization
  27. DB Quant: Secure Metrics, Part 1, Patch
  28. DB Quant: Secure Metrics, Part 2, Configure
  29. DB Quant: Secure Metrics, Part 3, Restrict Access
  30. DB Quant: Monitoring Metrics: Part 1, Database Activity Monitoring
  31. DB Quant: Monitoring Metrics, Part 2, Audit
  32. DB Quant: Protect Metrics, Part 1, DAM Blocking
  33. DB Quant: Protect Metrics, Part 2, Encryption
  34. DB Quant: Protect Metrics, Part 3, Masking
  35. DB Quant: Protect Metrics, Part 4, WAF

—Rich

The Open Source Database Security Project

By Adrian Lane

I am thinking about writing a guide to secure open source databases, including verification queries. Do you all think that would be useful?

For the most part, when I write about database security, I write about generic approaches that apply to all database platforms. I think this is helpful for database managers, as well as security and IT professionals who have projects that span multiple database types. When writing the Database Security Fundamentals series, my goal was to provide a universal checklist of the database security basics that anyone with basic DBA skills could accomplish in a week. DBAs who work in large enterprise may have established guidelines, but small and medium sized firms generally don’t, and I wanted the series to provide an awareness on what to look for and what to do. I also find that mainstream Oracle DBAs tune out because I don’t provide specific queries or discuss native features.

The downside is that the series covers what to do, but not how to do it. By taking a more abstract look at the problems to be solved across security and compliance, I cannot provide specific details that will help with Oracle, Sybase, Teradata, PostgreSQL, or others – there are simply too many policies for too many platforms for me to sufficiently cover. Most DBAs know how to write the queries to fulfill the policies I outlined. For the non-DBA security or IT professional, I recognize that what I wrote leaves a gap between what you should do and how to do it. To close this gap you have a couple of options:

  1. Acquire tools like DAM, encryption, and assessment from commercial vendors
  2. Participate on database chat boards and ask questions
  3. RTFM
  4. Make friends with a good DBA

Yes, there are free tools out there for assessment, auditing, and monitoring. They provide limited value, and that may be sufficient for you. I find that the free assessment tools are pretty bad because they usually only work for one database, and their policies are miserably out of date. Further, if you try to get assessment from a commercial vendor, they don’t cover open source databases like Derby, PostgreSQL, MySQL, and Open Ingres. These platforms are totally underserved by the security community but most have very large installed user bases. But you have to dig for information, and cobble together stuff for anything that is not a large commercial platform.

So here is what I am thinking: through the remainder of the year I am going to write a security guide to open source databases. I will create an overview for each of the platforms (PostgreSQL, Derby, Ingres and MySQL), and cover the basics for passwords, communications security, encryption options, and so forth, including specific assessment polices and rules for baselining the databases. Every week I’ll provide a couple new rules for one platform, and I will write some specific assessment policies as well. This is going to take a little resourcefulness on my part, as I am not even sure my test server boots at this point, and I have never used Derby, but what the heck – I think it will be fun. We will post the assessment rules much like Rich and Chris did for the ipfw Firewall Rule Set.

So what do you think? Should I include other databases? Should I include under-served but non-open-source such as MS Access and Teradata? Anyone out there want to volunteer to test scripts (because frankly I suck at query execution plans and optimization nowdays)?

Let me know because I have been kicking this idea around for a while, but it’s not fully fleshed out, and I would appreciate your input.

—Adrian Lane

DB Quant: Protection Metrics, Part 4, Web Application Firewalls

By Adrian Lane

Web Application Firewall deployment metrics are next up in the protection phase. This process is somewhat truncated compared to our other deployment processes, as the database administrator is tasked with only a subset of the overall effort that goes into WAF deployment. Regardless, there is a lot of work to be done for policy development and testing, and the process will be repeated many times over.

Our WAF deployment process is:

  1. Identify
  2. Profile
  3. Test
  4. Review
  5. Document

Identify

Variable Notes
Time to identify which databases are part of web applications

Profile

Variable Notes
Time to gather application query and parameter profiles i.e., What does the web application send to the database? Provide to the WAF team to generate rules/policies.

Test

Variable Notes
Time to analyze pre-deployment test results
Optional: time to retest

Review

Variable Notes
Variable: periodically review logs for failures e.g., check to see if rules broke any functionality
Variable: repeat Investigate task to adjust rules i.e., failed tests or policies need to be fixed
Time to investigate and remediate incidents WAF administrators should be managing most incidents, but DBAs are often involved for investigation and remediation of problems beyond rule failures

Document

Variable Notes
Time to document WAF rules

Other Posts in Project Quant for Database Security

  1. An Open Metrics Model for Database Security: Project Quant for Databases
  2. Database Security: Process Framework
  3. Database Security: Planning
  4. Database Security: Planning, Part 2
  5. Database Security: Discover and Assess Databases, Apps, Data
  6. Database Security: Patch
  7. Database Security: Configure
  8. Database Security: Restrict Access
  9. Database Security: Shield
  10. Database Security: Database Activity Monitoring
  11. Database Security: Audit
  12. Database Security: Database Activity Blocking
  13. Database Security: Encryption
  14. Database Security: Data Masking
  15. Database Security: Web App Firewalls
  16. Database Security: Configuration Management
  17. Database Security: Patch Management
  18. Database Security: Change Management
  19. DB Quant: Planning Metrics, Part 1
  20. DB Quant: Planning Metrics, Part 2
  21. DB Quant: Planning Metrics, Part 3
  22. DB Quant: Planning Metrics, Part 4
  23. DB Quant: Discovery Metrics, Part 1, Enumerate Databases
  24. DB Quant: Discovery Metrics, Part 2, Identify Apps
  25. DB Quant: Discovery Metrics, Part 3, Config and Vulnerability Assessment
  26. DB Quant: Discovery Metrics, Part 4, Access and Authorization
  27. DB Quant: Secure Metrics, Part 1, Patch
  28. DB Quant: Secure Metrics, Part 2, Configure
  29. DB Quant: Secure Metrics, Part 3, Restrict Access
  30. DB Quant: Monitoring Metrics: Part 1, Database Activity Monitoring
  31. DB Quant: Monitoring Metrics, Part 2, Audit
  32. DB Quant: Protect Metrics, Part 1, DAM Blocking
  33. DB Quant: Protect Metrics, Part 2, Encryption
  34. DB Quant: Protect Metrics, Part 3, Masking

—Adrian Lane

Incite 6/23/2010: Competitive Fire

By Mike Rothman

I’ve always been pretty competitive. For instance, back in high school my friends and I would make boasts about how we’d have more of this or that, and steal the other’s wife, etc. Yes, it was silly high school ego run rampant, but I thought life was a zero sum game back then. Win/win was not in my vocabulary. I win, you lose, that’s it.

Now that is some fireworks... I carried that competitive spirit into the first 15 years or so of my working career. At META, it was about my service selling more than yours. About me being able to stake out overlapping coverage areas and winning the research battle. In the start-up world, it was about raising the money and beating the other companies with similar stories & models.

Then in a variety of vendor gigs, each in very competitive market spaces, it was about competing and winning and having a better story and giving the sales team better tools to win more deals. Nothing was ever good enough – not at work, not at home, and not in my own head.

Yeah, I was frackin’ miserable. And made most of the people around me miserable as well.

When I was told my services were no longer needed at CipherTrust, I saw it as an opportunity to go in a different direction. To focus on helping folks do better, as opposed to winning whatever ‘needed’ to be won. It wasn’t exactly a conscious decision, but I knew I needed a change in focus and attitude. For the most part, it worked. I was much happier, I was doing better, and I was less grumpy.

Then I stepped back into corporate life, but to be honest, my heart wasn’t in it. I didn’t care if we lost a specific deal because we should be able to get into a lot of deals and statistically we’d be OK. Of course, I had to mask that indifference, but ultimately for a lot of reasons it didn’t make sense for me to continue in that role. So I left and got back to where I could help folks, and not worry about winning.

But you can’t entirely escape competition. Now I play softball on Sundays with a bunch of old guys like me. But some of them still have that competitive fire burning and to be honest it gets annoying. When someone boots a ground ball or lines out with runners on, these guys get all pissed off. We lost a one-run game last Sunday, after coming back from 3 runs down in the last inning. I was happy with that effort – we didn’t give up. Others were pissed.

Personally, I play softball because it’s fun. I get outside, I run around, I get my couple of at-bats and make a few plays in the field. But when guys get all uppity about not winning or someone making a mistake, it’s demotivating to me. I’ve got to find a way to tune out the negativity and still have fun playing. Or I’ll need to stop, which is the wrong answer. But I am working too hard to be positive (which is not my default mode) to hang around with negatives.

Yes, I like to win. But I don’t need to win anymore. And I’m a lot happier now because of it. But that’s just me.

– Mike.

Photo credits: “win win” uploaded to Flickr by TheTruthAbout…


Recent Securosis Posts


Incite 4 U

  1. Different NAC strokes for different folks – A few weeks ago, Joel Snyder talked about what went wrong with NAC. It was a good analysis of the market issues. Joel’s conclusion is that there isn’t really a standard set of NAC features, but rather a number of different breeds. Which basically means there is no market – not a consistent one, anyway. No wonder the category has struggled – nobody can agree on what problem the technology is supposed to solve. Joel also points out some of the political issues of deploying a solution that spans network, endpoint, and security teams. This week, NetworkWorld published the Joel’s review. He does likes some of the products (those based on 802.1X like Avenda, Enterasys, and Juniper), and has issues with some of the others (ForeScout and TrustWave). But ultimately the review highlights the reality of the market, which is that there isn’t one. – MR

  2. DRM dreams – Designing DRM systems in 1996, I had big hopes that digital lockers would be a popular choice to secure content for people to share on the Internet. I thought everyone from banking systems to media distribution could benefit. By 1998 that dream faded as nobody was really interested in secure content storage or delivery. But it turns out someone has the same dreams I did: hackers embrace DRM as a way to hide pirated content as reported on Yahoo! News. Basically pirated video is wrapped up in a protective blanket of encryption, which can then be moved and stored freely, without detection by content analysis tools. Porn, pirated movies, and whatever else, can be distributed without fear of being inspected and discovered. And this model works really freaking’ well when the buyer and seller want to keep their activity a secret. Hollywood may have complained bitterly about pirated DVDs, but this particular delivery model will be near impossible to stop. No, Cyber-nanny will not cut it. There are only a handful of ways to catch and prosecute this type of crime. Law enforcement will have to figure out how to police the exchange of decryption keys for money. – AL

  3. Disclosure is religion – I’ve been known to write and talk about the disclosure debate, but I’m starting to wonder if it’s worth the effort. Disclosure has clearly become religion, with everyone believing what they want, nothing more than anecdotal evidence to support anyone’s position, and enough logical fallacies on all sides to fill all the empty heads at a Crossing Over with John Edward show. Tyler Reguly wades in with an informed and reasonable post on the relationship between Full Disclosure and Responsible Disclosure that’s worth a read, but I don’t expect it to change any minds. I worry that even if we ever do get the kinds of studies and data we need to make informed disclosure decisions, they will be ignored faster than evolution in a Texas school book (how’s that for troll bait?!) – RM

  4. Cyber-insurance a messy business – When there are no precedents, things inevitably get messy. As Ed points out on the SecurityCurve blog, an insurer called Colorado Casualty is basically making a pre-emptive strike against the University of Utah to protect against any potential claims from a set of lost tapes (that triggered a $3.3MM disclosure). Is Colorado Casualty wrong? Without precedent, there is no way to know. It seems like your typical insurance company crap of not wanting to pay even when they should, but who knows? And it will take a few years and lots of legal fees to figure out what is right and wrong. Until then, understand that cyber-insurance may not insure you from much of anything. – MR

  5. iPhone encryption trick – If you have an iPhone 3GS or later there is hardware encryption on the device to protect your data. But Apple screwed the pooch on the implementation which basically made the encryption worthless. But the good news is they seem to have fixed this in the just-released iOS 4 software, although you need to take a couple extra steps to make it work. The new version uses your passcode to protect the encryption keys, assuming they got it right this time. If you buy a new iPhone 4 it is enabled by default if you use a passcode, but as described in this support note, you need to take a couple extra steps to enable the improved encryption if you upgraded your device. I hope this works… – RM

  6. Einstein not so smart? – I guess Stiennon isn’t happy with his infamy in declaring IDS dead 10 or so years ago. So now he’s getting on his soapbox and saying DHS’s Einstein project (basically a mondo-IDS) is all wrong. Of course, he doesn’t offer any solutions in the piece or directions on how to make it better. The issues he points out (information overload, lack of staffing) are real. But you need to monitor to know what is going on. Period. The real gap thus far is how to deal with the amount of data – and more importantly how to fix the issues you find. Calling Einstein stupid doesn’t solve the problem. Richard is a smart guy and it would be great to see less rhetoric and more constructive ideas. Though I’m sure all is divulged in Richard’s book. ;-) – MR

  7. Cloudy value, crystal clear motivation – Mike Vizard has been running a series of posts on application testing, with liberal quotes from Aparna Sharma of Infosys Technologies. The entire mindset – premises and approach – is totally backwards. First, having application developers test their own code is not “a case of the fox guarding the hen house”. Developers are not the ones hacking their own code, so this is a B.S. argument. Second, it’s not a huge burden to run automated tests. Many developers link test cases into nightly builds for component and module sanity tests for both security and quality. Test cases requiring complete builds are usually run by QA. The pain in the ass is figuring out if the results are useful or just more false positive garbage. Third, automated application testing has its place, but it’s not a substitute for manual testing. In fact you do both, leveraging the strengths of each where needed – both for coverage and to reduce costs. Finally, the bias towards manual testing is because it is effective: the preference is to automate when possible. Reviewing code is hard work, and very few people are qualified to do it or like to do it. Remember that development teams create libraries of code, trusted both to function and to be secure, to minimize the need to do automated or manual tests. It’s not like you need the limitless resources of the cloud to perform automated testing – ‘the cloud’ is just a convenient delivery model. – AL

  8. The benefit of copying – So how do you get security kung fu and/or improve your skills? Take some advice from the folks at 37Signals and copy someone you respect. 37S is talking about design, but the same method can apply to security. With the advent of lots of video content available nowadays, you can see someone else do something cool, mostly for free. I guess you could go to a hands-on education class, but I’ve found seeing someone else do something and then screwing it up myself is the best way for me to learn. Check out Mubix’s Practical Exploitation and The Academy Pro (mostly vendor stuff); and we know of a few other folks planning detailed video courses, so we expect the amount of content available to mushroom over the next 18 months. – MR

—Mike Rothman

Tuesday, June 22, 2010

DB Quant: Protect Metrics, Part 3, Masking

By Adrian Lane

Masking is the next phase of protective controls in our series. As a reminder, most firms decide to use either ETL or dynamic masking – we cover both in the metrics and process below, but they require slightly different product evaluation, details of which are beyond our scope here. As with encryption, masking is an add-on tool for databases and applications, so I have removed the ‘optional’ tag from the cost metrics.

It’s worth noting during the setup phase that masking tools have numerous options for retaining original data type, format, data ranges, etc. Depending on the tool, you can configure the mask to maintain referential integrity, or emit numeric values to mimic original sums and averages. Plan on spending time to refining the masks during setup.

Our masking process is:

  1. Plan
  2. Acquire
  3. Setup
  4. Deploy & Test
  5. Document

Plan

Variable Notes
Time to confirm data security and compliance requirements
Time to identify preservation requirements e.g., last 4 digits of credit card, format, data type
Time to specify masking model e.g., ETL, in place, etc.
Time to generate baseline e.g., gather sample data and formats for testing

Acquire

Variable Notes
Time to evaluate masking products
Cost to acquire masking products/packages
Time to acquire access and authorization to data systems Credentials to implement mask on sensitive data

Setup

Variable Notes
Time to install masking tools
Time to select masks and masking options e.g., to preserve value, consistency, and referential integrity
Time to configure Implement masks

Deploy & Test

Variable Notes
Time to perform transformations e.g., create extraction or view
Time to verify masks i.e. data is masked, format is preserved, and applications still work
Time to collect sign-offs and approval

Document

Variable Notes
Time to document masks and configuration settings

Keep in mind that masking is a cycle, not a one-time operation. You’ll need to adjust the metrics for ongoing masking projects, but these will leverage initial investments so you won’t be repeating all costs.


Other Posts in Project Quant for Database Security

  1. An Open Metrics Model for Database Security: Project Quant for Databases
  2. Database Security: Process Framework
  3. Database Security: Planning
  4. Database Security: Planning, Part 2
  5. Database Security: Discover and Assess Databases, Apps, Data
  6. Database Security: Patch
  7. Database Security: Configure
  8. Database Security: Restrict Access
  9. Database Security: Shield
  10. Database Security: Database Activity Monitoring
  11. Database Security: Audit
  12. Database Security: Database Activity Blocking
  13. Database Security: Encryption
  14. Database Security: Data Masking
  15. Database Security: Web App Firewalls
  16. Database Security: Configuration Management
  17. Database Security: Patch Management
  18. Database Security: Change Management
  19. DB Quant: Planning Metrics, Part 1
  20. DB Quant: Planning Metrics, Part 2
  21. DB Quant: Planning Metrics, Part 3
  22. DB Quant: Planning Metrics, Part 4
  23. DB Quant: Discovery Metrics, Part 1, Enumerate Databases
  24. DB Quant: Discovery Metrics, Part 2, Identify Apps
  25. DB Quant: Discovery Metrics, Part 3, Config and Vulnerability Assessment
  26. DB Quant: Discovery Metrics, Part 4, Access and Authorization
  27. DB Quant: Secure Metrics, Part 1, Patch
  28. DB Quant: Secure Metrics, Part 2, Configure
  29. DB Quant: Secure Metrics, Part 3, Restrict Access
  30. DB Quant: Monitoring Metrics: Part 1, Database Activity Monitoring
  31. DB Quant: Monitoring Metrics, Part 2, Audit
  32. DB Quant: Protect Metrics, Part 1, DAM Blocking
  33. DB Quant: Protect Metrics, Part 2, Encryption

—Adrian Lane

Understanding and Selecting SIEM/LM: Deployment Models

By Adrian Lane

We have covered the major features and capabilities of SIEM and Log Management tools, so now let’s discuss architecture and deployment models. Each architecture addresses a specific issue, such as coverage for remote devices, scaling across hundreds of thousands of devices, real-time analysis, or handling millions of events per second. Each has advantages and disadvantages in analysis performance, reporting performance, scalability, storage, and cost.

There are four models to discuss: ‘flat’ central collection, hierarchical, ring, and mesh. As a caveat, none of these deployment models is mutually exclusive. Some regions may deploy a flat model, but send information up to a central location via a hierarchy. These are not absolutes, just guidelines to consider as you design your deployment to solve the specific use cases driving your project.

Flat

The original deployment model for SIM and log management platforms was a single server that collected and consolidated log files. In this model all log storage, normalization, and correlation occurs within a central appliance. All data collection methods (agent, flow, syslog, etc.) are available, but data is always stored in the same central location.

A flat model is far simpler to deploy. All data and policies reside in a single location, so there are no policy or data synchronization issues. But of course ultimately a flat central collection model is limited in scalability, processing, and the quantity of data it can manage. A single installation provides a fixed amount of processing and storage, and reporting becomes progressively harder and slower as data sets grow. Truth be told, we only see this kind of architecture for “checkbox compliance”, predominately for smaller companies with modest data collection needs.

The remaining models address the limitations of this base architecture.

Hierarchical

The hierarchical model consists of a central SIEM server, similar to the flat model above. Rather than communicating directly with endpoints where data is collected, the central SIEM server acts as a parent, and communicates with intermediary collection appliances (children). Each child collects data from some of the devices, typically from a specific region or location. The regional child nodes collect and store data, then normalize events before passing them along to the central SIEM server for aggregation, correlation, and reporting. Raw event data remains on the local child for forensic purposes.

The hierarchical model was introduced to help scale across larger organizations, where it wasn’t practical to send the raw data streams across the network and some level of storage tiers were required for scaling. The hierarchical model helps divide and conquer data management challenges by distributing load among a larger number of engines, and reduces network overhead by only passing a subset of the captured data to the parent for correlation and analysis. Data storage, backup, and processing are much easier on smaller data sets. Further, construction of reports can be distributed across multiple nodes – important for very large data sets.

There are many variations on this model, but the primary point is that the parent and child nodes each take on different responsibilities. Depending upon the vendor alerting, filtering, normalization, reporting, and anything else having to do with policy enforcement can be part of the parent or the child, but not both. The good news is you can scale up by adding new child nodes. The downside is that every function handled by the child nodes requires synchronization with the server. For example, alerting is faster from the child node, but requires distribution of the code and policies. Further, alerting from the child node(s) lacks correlation of events to refine the accuracy of alerts. Despite the trade-offs, this hierarchical model is very flexible.

Ring

In the Ring model – or what Mike likes to call the Moat – you have a central SIEM server ringed by many log collection devices. Each logger in the ring is responsible for collecting data from event sources. These log archives are also used to support distributed reporting. The log devices send a normalized and filtered (so substantially reduced) stream of events to the master SIEM device. The SIEM server sitting in the middle is responsible for correlation of events and analysis. This architecture was largely designed to address scalability limitations with some SIEM offerings. It wasn’t cost effective to scale the SIEM engine to handle mushrooming event traffic, so surrounding the SIEM centerpiece with logging devices allowed it to analyze the most critical events while providing a more cost-effective scaling mechanism.

The upside of this model is that simple (cheaper) high-performance loggers do the bulk of the heavy lifting, and the expensive SIEM components provide the meat of the analysis. This model addresses scalability and data management issues, while reducing the need to distribute code and policies among many different devices.

There are a couple issues with the ring model. The biggest problem remains a lack of integration between the two systems. Management tools for the data loggers and the SIEM may be linked together with some type of dashboard, but you quickly discover the two-headed monster of two totally separate products under the covers. Similarly, log management vendors were trying to graft better analysis and correlation onto their existing products, resulting in a series of acquisitions that provided log management players with SIEM. Either way, you end up with two separate products trying to solve a single problem. This is not a happy “you got your chocolate in my peanut butter,” moment, and will continue to be a thorny issue for customers until vendors fully integrate their SIEM and log management offerings as opposed to marketing bandaids dashboards as integrated products.

Mesh

The last model we want to discuss is the mesh deployment. The mesh is a group of interrelated systems, each performing full log management and SIEM functions for a small part of the environment. Basically this is a cluster of SIEM/LM appliances; each a functional peer with full analysis, correlation, filtering, storage, and reporting for local events. The servers can all be linked together to form a mesh, depending on customer needs.

While this model is more complex to deploy and administer, and requires a purpose-built data store to manage high-speed storage and analysis, it does solve several problems. For organizations that require segregation of both data and duties, the mesh model is unmatched. It provides the ability to aggregate and correlate specific segments or applications on specific subsets of servers, making analysis and reporting flexible. Unlike the other models, it can divide and conquer processing and storage requirements flexibly depending on the requirements of the business, rather than the scalability limitations of the product being deployed.

Each vendor’s product is capable implementing two or more of these models, but typically not all of them. Each product’s technical design (particularly the datastore) dictates which deployment models are possible. Additionally, the level of integration between the SIEM and Log Management pieces has an effect as well. As we said in our introduction, every SIEM vendor offers some degree of log management capability, and most Log Management vendors offer SIEM functions. This does not mean that the offerings are fully integrated by any stretch. Deployment and management costs are clearly affected by product integration or lack thereof, so make sure to do your due diligence in the purchase process to understand the underlying product architecture and the limitations and compromises necessary to make the product work in your environment.

—Adrian Lane

Trustwave, Acquisitions, PCI, and Navigating Conflicts of Interest

By Rich

This morning Trustwave announced their acquisition of Breach Security, the web application firewall vendor.

Trustwave’s been on an acquisition streak for a while now, picking up companies such as Mirage (NAC), Vericept (DLP), BitArmor (encryption), and Intellitactics (log management/SIEM). Notice any trends? All these products have a strong PCI angles, none of the companies were seeing strong sales (Trustwave doesn’t do acquisitions for large multiples of sales), and all were more mid-market focused.

Adding a WAF to the mix makes perfect sense, especially since Trustwave also has web application testing (both controls meet PCI requirement 6.6). Trustwave is clearly looking to become a one-stop shop for PCI compliance. Especially since they hold the largest share of the PCI assessment market.

To be honest, there are concerns about Trustwave and other PCI assessment firms offering both the assessment and remediation services. You know, the old fox guarding the henhouse thing. There’s a reason regulations prohibit financial auditors from offering other services to their clients – the conflicts of interest are extremely difficult to eliminate or even keep under control. When the person making sure you are compliant also sells you tools to help become compliant, we should always be skeptical.

We all know how this goes down. Sales folks will do whatever it takes to hit their numbers (you know, they have BMW payments to make), and few of them have any qualms about telling a client they will be compliant if they buy both their assessment services and a nice package of security tools and implementation services. They’ll use words like “partners” and “holistic” to seem all warm and fuzzy.

We can’t really blame Trustwave and other firms for jumping all over this opportunity. The PCI Council shows no interest in controlling conflicts of interest, and when a breach does happen the investigation in the kangaroo court will show the company wasn’t compliant anyway.

But there is also an upside. We also know that every single client of every single PCI assessment, consulting, or product firm merely wants them to make PCI “go away”, especially in the mid-market. Having firms with a complete package of services is compelling, and companies with big security product portfolios like Symantec, McAfee, and IBM aren’t well positioned to provide a full PCI-related portfolio, even though they have many of the pieces.

If Trustwave can pull all these acquisitions together, make them good enough, and hit the right price point, the odds are they will make a killing in the market. They face three major challenges in this process:

  1. Failing to properly manage the conflicts of interest could become a liability. Unhappy customers could lead to either bad press and word of mouth, or even changes in PCI code to remove the conflicts, which they want to avoid at all costs. The actual assessors and consultants are reasonably well walled off, but they will need to aggressively manage their own sales forces to avoid problems. Ideally account execs will only sell one side of the product line, which could help manage the potential issues.
  2. Customers won’t understand that PCI compliance isn’t the same as general security. Trustwave may get the blame for non-PCI security breaches (never mind the real cardholder data breaches), especially given the PCI Council’s history of playing Tuesday morning QB and saying no breached organization could possibly be compliant (even if they passed their assessment).
  3. Packaging all this together at the right price point for the mid-market won’t be easy. Products need real integration, including leveraging a central management console and reporting engine. This is where the real leverage is – not merely services-based integration, which is not good enough for the mid-market.

So the Breach acquisition is a smart move for Trustwave, and might be good for the market. But as an assessor, Trustwave needs to carefully manage their acquisition strategy in ways mere product mashup shops don’t need to worry about.

—Rich

DB Quant: Protect Metrics, Part 2, Encryption

By Adrian Lane

Continuing the Protect phase, we now dig into one of the most important sections: encryption. There are several forms of database encryption, but the proposed process and associated metrics should encompass both transparent encryption and internal API calls to encrypt columns and tables. Keep in mind that for this project we are only accounting for work associated with the database, and this does not include time spent altering queries and applications to accomodate non-transparent encryption options.

In our previous post to introduce the process, we stated that the cost of acquiring encryption products was optional. Actually, that’s not true. You really don’t want to write your own, so you either need to purchase this capability, or already have purchased an encryption tool set. The same is true for external key management. If the products have already been purchased, you will need to make a decision to factor all or part of the cost into this estimate.

Our encryption process is:

  1. Evaluate
  2. Acquire
  3. Test & Approve
  4. Deploy & Integrate
  5. Document

Evaluate

Variable Notes
Time to confirm data security requirements
Time to identify encryption method and tools e.g., native database, OS
Time to identify integration requirements e.g., external key management, key rotation, disaster recovery considerations

Acquire

Variable Notes
Time to evaluate encryption tools
Cost to acquire encryption products/packages
Optional: Cost to acquire key management
Variable: Cost of maintenance and support licenses Native transparent encryption cost is likely to be in addition to base database license

Test & Approve

Variable Notes
Time to establish test environment
Time to install and configure encryption tool Test environment configuration
Time to test Verify data is encrypted, backup procedures still work, etc.
Time to establish disaster recovery process & procedures i.e., keys and supporting services need to be accounted for
Time to collect sign-offs and approval Verify efficacy of encryption, and that systems pass test cases
Time to create database archive Archive & verify production backup

Deploy & Integrate

Variable Notes
Time to install encryption into production environment
Time to install key management server (if used) and generate keys Keys need to be generated regardless
Time to deploy, encrypt data, and set authorization rights
Time to integrate with applications, backup, and authentication systems

Document

Variable Notes
Time to document configuration and key management settings

As we said in this introduction, we aren’t including the costs associated with application changes that may be required, depending on which encryption option you deploy. This is something you will definitely want to include in your metrics, even though they are beyond the scope of this framework.


Other Posts in Project Quant for Database Security

  1. An Open Metrics Model for Database Security: Project Quant for Databases
  2. Database Security: Process Framework
  3. Database Security: Planning
  4. Database Security: Planning, Part 2
  5. Database Security: Discover and Assess Databases, Apps, Data
  6. Database Security: Patch
  7. Database Security: Configure
  8. Database Security: Restrict Access
  9. Database Security: Shield
  10. Database Security: Database Activity Monitoring
  11. Database Security: Audit
  12. Database Security: Database Activity Blocking
  13. Database Security: Encryption
  14. Database Security: Data Masking
  15. Database Security: Web App Firewalls
  16. Database Security: Configuration Management
  17. Database Security: Patch Management
  18. Database Security: Change Management
  19. DB Quant: Planning Metrics, Part 1
  20. DB Quant: Planning Metrics, Part 2
  21. DB Quant: Planning Metrics, Part 3
  22. DB Quant: Planning Metrics, Part 4
  23. DB Quant: Discovery Metrics, Part 1, Enumerate Databases
  24. DB Quant: Discovery Metrics, Part 2, Identify Apps
  25. DB Quant: Discovery Metrics, Part 3, Config and Vulnerability Assessment
  26. DB Quant: Discovery Metrics, Part 4, Access and Authorization
  27. DB Quant: Secure Metrics, Part 1, Patch
  28. DB Quant: Secure Metrics, Part 2, Configure
  29. DB Quant: Secure Metrics, Part 3, Restrict Access.
  30. DB Quant: Monitoring Metrics: Part 1, Database Activity Monitoring
  31. DB Quant: Monitoring Metrics, Part 2, Audit
  32. DB Quant: Protect Metrics, Part 1, DAM Blocking

—Adrian Lane