Secure Your Apps Like a Vegas Casino – InApps Technology 2022

High-tech casino heists make great fodder for Hollywood. They also provide a relatable model for application and infrastructure security that enterprises might want to emulate. The idea is simple: High-end Las Vegas casinos use a multilayered security model with guards at the front door to establish the perimeter of a trusted zone and many more mechanisms inside the perimeter to further secure specific areas within the zone.

The strongest security measures protect the counting rooms and chip cages — so strong that in the classic heist movie “Ocean’s 11,” a team of cunning and skilled thieves can get into those areas only by knocking out power to the entire city of Las Vegas. At the other end of the security spectrum is the casino floor, which is open to anyone off the street who doesn’t look suspicious to the entry staff. In between, there are:

• “High-roller” gambling rooms, with more security and monitoring than the regular casino floor to limit entry only to pre-approved wealthy players.
• Floors of guest rooms reachable by elevator for anyone with a room key.
• Restricted VIP floors where the elevators require another type of security token beyond a room key.

Similarly, employees have access to certain parts of the casino based on their job roles — for example, badges for kitchen staff limit their access to the kitchen, restaurant and employee bathrooms only, while the security staff can go everywhere.

This Gordian Knot of needs is a good analogy for the modern application and microservice environment. Functions and requirements are tightly coupled to each service. All guests need access to monolithic services like the elevators and the hotel gym. The microservices for functions like counting chips or serving food have their own requirements for application security, latency and resiliency. Each service may have its own pace of iteration and change. Menus change daily, whereas room-cleaning procedures and amenities change once per year, if that, or because of a once-in-a-century pandemic. The most sensitive services must be robust and resilient enough to survive earthquakes — real or simulated, the lynchpin of the heist in the third installment of the “Ocean’s” trilogy — massive electronic shocks and total system crashes.

Design Applications to Stop a Team of Thieves

Casinos are fascinating exercises in architecture and design that mimic the reality of modern mixed application environments. They also evoke some physical world attributes of Zero Trust. More than any other organization, save perhaps airlines, casinos treat humans passing through the environment like packets with different levels of privilege and authentication.

The front desk and doormen are the basic security checkpoints. They watch folks coming in for any obvious signs of trouble. Because casinos want every visitor to gamble or eat, or both, they don’t issue passes or keycards at the door, but someone is always watching. Casinos have pervasive biometric identification backends, in part because they need to look out for card counters and gangs that work together to gain an advantage at the tables with games like Blackjack. So even though it feels like you’re free to move about in the public areas, you are being monitored. Undesirables are often spotted when they enter and are promptly asked to leave. In that sense, the public area of a casino functions like a modern, intelligent firewall with anomaly detection for lists of attack signatures and bad IP addresses (card counters).

The next level of security is to get onto the floors with guest rooms and amenities like spas or gyms. There are even gradations with these areas. Most casinos have a set of exclusive invitation-only areas for high rollers. The casino’s operations or security team can determine which rooms are accessible to which types of customers and might add complementary layers of more sophisticated security measures, such as fingerprint readers or retinal scanners. The advantage of separate layers is that security teams can make necessary changes on a limited scale, rather than having to replace all the cameras in the lobby and reconfigure the layout of the casino floor. Duplicate, layered and complementary security equals more effective and flexible security.

The more secure areas of a casino are like the applications managed by an agile DevOps team. The same way that the DevOps team decides how often to update a service independent of other services, the concierge in charge of high rollers can order the special snack that one of them likes to have when she plays poker without getting approval from the general manager. The security team dedicated to the high rollers’ area can set up different levels of security for different subareas. For example, access to a card room is granted only to the players in a game starting at a particular time, whereas all high rollers can go to the spa at any time during their stay. The security team can also modify standards and procedures for different circumstances: If the richest person in the world is coming to gamble, security in areas where they might go should be considerably tighter than usual.

The most secure locations are the ones where the money is counted or stored. These are areas where security is the only metric that matters;  guards, cameras, motion capture, machine vision and lots of other high-tech measures are commonplace. People cannot go in and out of these areas without high levels of scrutiny and, usually, multifactor authentication. To access these locations, workers must typically pass several security guards and multiple video cameras. The parallel in the app world are the parts of applications that deal with financial information or personal identifiable information (PII). Casinos segment off this part of their applications and it becomes a continuous Zero Trust assessment realm living on its own networks and with its own set of security tooling and protocols.

However, everyone and everything that gets to the counting room still must go through basic security procedures — having their badge read at the employee entrance, for example. There are basic policies that apply to everyone and then, for access to more sensitive areas, the policies grow more intricate and independent. Think of the front desk and security on the casino floor as the sharp edge of SecOps (guarding perimeter and common spaces), whereas the more involved security measures guarding highly sensitive areas are like DevSecOps, guarding the crown jewels and endowed with more agility and flexibility. Again, complementary security systems are the way casinos, and organizations with a good security posture, handle the different security requirements for different applications.

How to (Not) Roll the Security Dice with Modern Apps

Like the casino described above, modern application environments are complicated and have different needs related to security, delivery and code development velocity. For example, constantly revving your database architecture probably isn’t wise, but continuously updating your frontend code to make small improvements and implement new user-facing features is. Plus, more and more of that frontend will tap into external APIs and services over time. The backend, however, will not.

Similarly, a service’s function matters a lot with respect to security. A service that handles payments requires a higher level of security than one that processes images. Security considerations may not always be obvious, either. It might be more important that you think to secure internal service-to-service traffic in modern apps. Although it looks like that traffic travels down a closed corridor, it can provide an easy path to horizontal traversal and privilege escalation. This is especially true in Kubernetes-driven environments, where all communication is via API and functions very much like the communications on the public internet.

At the same time, microservice applications must coexist happily with legacy monolithic applications, which are likely to be around for decades. (If you don’t believe me, join me on a field trip to the data centers of a few big banks — be sure to brush up on your Fortran skills beforehand.) Monolithic applications change more slowly, are often removed from CI/CD processes and operate in a vastly different deployment environment than microservices. The resulting hybrid development and deployment model creates challenges for all the teams trying to get their jobs done, from individual developers, to DevOps, DevSecOps and NetOps teams, all the way up to the CTO and CIO. How can you make rules, policies and workflows that accommodate all their needs without constantly having to remodel? The answer is to set up additive and complementary security tracks.

Conclusion: Security Flexibility Ensures Agility

We too often think of security as rigid and driven by SecOps, otherwise known as the “No!” team. CISOs have never enjoyed this description. With cloud computing and modern applications that evolve quickly and ship code prodigiously, “just say no” is no longer an option. Enterprises must figure out how to apply basic security to their entire organization while offering different levels of security — and the ability to control the way that security is designed and applied — to teams running different applications in different ways. That’s why the most paranoid enterprises in the world, Las Vegas casinos, offer complementary layers with great flexibility on a per-use-case basis and deliver high levels of security that you can take to the bank.

Featured image via Pixabay.