After spending this week at the Blackhat/DefCon 19 conferences, I was struck with this thought - Web application security monitoring could take a few pointers from Casino Surveillance.
Network Security and Banks
Traditional network security seems to have a similar security posture philosophy as brick-and-mortar banks - Keep the bad buys out. For banks, the goal is to keep the money in the vaults to make sure that criminals do not obtain access to it. Network security similarly aims is to keep outsiders from accessing internal systems and ports.
Web Application Security and Casino Surveillance
Web application security and monitoring, on the other hand, is very similar to Casino Surveillance in that the goal is not to keep the bad guys out since - you have to let the people play. The very nature of both a Casino and a web application is to allow people access to the resources. The issue is not as much who you are but rather what you are doing. Yes, there is security at Casinos but they are not guarding the front door and checking IDs to get in the front door. They have to let people in to play the various games and then they need to watch them very closely looking for abnormal behaviors. While there are certain similarities to their operating model, there is a stark contrast to their monitoring capabilities and response actions.
The overwhelming majority of web applications have not been properly instrumented for logging transactional data and alerting on suspicious behaviors. When suspicious activities are suspected or illegal activities are confirmed, Casino security handles the situations quite differently than most web applications. The mantra for Casinos is - Contain the threat, don't upset other users and keep the business open. Unfortunately, most web application contingency plans for attacks are to shut down the site entirely until they can get a handle on the damage. If Casinos used this operating model, they would be out of business in a week. Monitoring and response, I believe, is where web applications could learn a lesson or two from Casinos.
Surveillance is not a luxury
Implementation of proper surveillance inside a Casino is not a luxury but is actually mandated by law (example
Nevada Gaming Commission document on surveillance standards). While the
PCI Digital Security Standard (DSS) does outline some audit details in Requirement 10, it still falls short on specific items that should be logged and/or flagged in web transactions. The
OWASP AppSensor Project is the closest resource I have found that highlights the types of events that web applications should be logging and alerting on. As good as AppSensor is for describing the types of events to look for, it does not cover HTTP auditing itself.
Proper Coverage
Casino surveillance cameras must be able to observe all aspects of the games including the equipment, staff and players. This includes the table layouts, the rack, chips and even view player's faces. Here is one section that outlines exactly what parts of table games must be covered for surveillance purposes:
STANDARD 2
REQUIRED SURVEILLANCE COVERAGE: TABLE GAMES
1. The surveillance system of all licensees operating three (3) or more table games must possess the capability to monitor and record:
(a) Each table game area, with sufficient clarity to identify patrons and dealers; and
(b) Each table game surface, with sufficient coverage and clarity to simultaneously view the table bank and determine the configuration of wagers, card values and game outcome.
2. Each progressive table game with a potential progressive jackpot of $25,000 or more must be recorded and monitored by dedicated cameras that provide coverage of:
(a) The table surface, sufficient that the card values and card suits can be clearly identified; and
(b) An overall view of the entire table with sufficient clarity to identify patrons and dealer.
(c) A view of the progressive meter jackpot amount. If several tables are linked to the same progressive jackpot meter, only one meter need be recorded.
In typical web application security logging, only a small subset of data is actually logged or reviewed. The data capture by most web servers is not adequate for conducting incident response. For example, most times, request and response bodies are excluded from logging which leaves a gaping blind spot. Anton Chuvakin and Gunnar Peterson have a very good paper entitled "
How to do Application Logging Right" that is certainly worth a read.
Combination of recording and live analysis
Casino cameras record all data and this information is stored for later use such as settling game disputes. If there are any problems, they can review the tapes to identify what happened. In addition to the recorded data, all Casinos have staff who are constantly monitoring and moving cameras to zero in on suspicious activity. In web application security monitoring, this is similar to having alerting systems based on rules such as those in AppSensor and then supplementing that with full audit logging. When an analyst identifies an initial event of interest, they can then utilize the full HTTP audit log data for correlations.
Just Doesn't Look Right (JDLR)
Following proper procedures in Casinos is absolutely critical for identifying scams and cheating behavior. When staff or players deviate from these procedures, then something just doesn't look right (jdlr) and the surveillance staff can then call up increased camera coverage to focus in on the suspects. This is somewhat similar to scenarios where web application firewalls have automated learning/profiling and create positive security rules for the expected web application behavior. If a client deviates from this profile, then anomaly events can be generated. It is possible to then increase the audit logging and "tag" these clients actions for recording their traffic.
Two Types of Crimes
Casinos typically have two types of crimes, crimes against the casino and crimes against the patrons. Crimes against the casino might be where scam artists work in teams to distract staff and pass cards between themselves or possible using tools/electronics against the computerized slot machines. In web application security, these would be similar to SQL Injection types of attacks where the attacker is aiming to attack the application itself to steal data.
Casino crimes against the patrons are scenarios where cheaters try and snatch other players chips, etc... In webappsec, this would be similar to XSS/CSRF types of attacks that aim to attack the end user through the web application.
Anyone can be a cheat
It would be fool hearty to only focus on stereotypes when attempting to identify cheats. Cheats come in all shapes, sizes and ages. Once again, it is not who you are but what you are doing. Similarly, in webappsec, while there is some useful IP reputation data that can be used, you must actually review what the web transaction is actually doing in order to be able to identify possible malicious behavior.