Pack Line Cloud Security

Basketball season is in full swing. I have been lucky for the last seven years to coach different levels of basketball ranging from Youth teams through the local High School team. Coaching continues to be a rewarding experience and many of the lessons I have learned working with athletes and other coaches apply directly to my work with product teams. It doesn’t matter how much you work to perfect your craft, be it system architecture or coaching a team of 5th grade athletes, there are always new challenges to tackle. A core tenant of sports is continuous improvement which should be applied to everything we do with technology. No one starts playing basketball ready to play in the pros, but everyone has it in them to be successful. It takes a tremendous amount of practice, a dedication to learning new things from others, and celebrating the little victories along the journey.

It is not surprising there are so many different Cloud Security analogies available on the Internet. Cloud Security is a difficult concept to describe given the wide range or tools, services, and seemingly infinite combinations organizations can utilize to solve business problems. If you are a fan of basketball, using different defensive schemes is a great way to describe different views on Cloud Security processes. In all cases, the goal is to prevent the offense, or in this case bad actors, from scoring while providing dynamic responses to a constantly changing product architecture and threat landscape. Typical Cloud Security frameworks today can be compared to two classic defenses: man-to-man and zone.

Man-to-Man

Man-to-Man Cloud Security involves security controls developed around individual services of products. Each control is focused on denying the service from sending or receiving information to other services in the system and aggressively focusing on protecting a single service. Firewalls, both web application and network, focus on denying traffic to block bad actors from easily accessing services. Logging and application specific analytics can be used to build a profile of a service and alert when the service profile is not followed. The disadvantage with man-to-man Cloud Security is in its aggressive focus on the individual service and a lack of real understanding of the big picture. There is a general lack of information on what other services are doing and because of this, any weakness in the focus on a single service can lead to breakdown of the security in general and, in basketball terms, an easy lay-up.

2-3 Zone

Zone Cloud Security primarily revolves around the frameworks in place for infrastructure deployed to support a wide variety of services. We still see organizations bringing the rigid security frameworks utilized for years in brick and mortar data centers and trying to apply them to Cloud Security. Deployed like a 2-3 zone in basketball, the defensive posture is to watch a specific area of the infrastructure and report back to a central service for monitoring and support. As information travels through the zone, communication is critical to ensure nothing gets lost in the shuffle. Each position in the zone is devoted to a specific task supporting a number of different services including both perimeter and core defense. The disadvantage with any zone defense is the gaps and in the public cloud space, gaps are appearing every day.

Server-less architectures are an exciting approach to utilizing the true power of elastic capacity while providing developers easier and easier ways to deploy features to production environments. However, in reducing the amount of infrastructure under direct monitoring the threat surface area is increasing at an equal rate. As any basketball coach will tell you, the easiest way to defeat a zone defense is by moving the ball and attacking the gaps in the zone. Another easy lay-up.

Trility takes a different approach to Cloud Security: the pack line.

Pack-Line

Pack Line Defense, created by Dick Bennett of Wisconsin-Stevens Point, is commonly used in some form by many coaches including Tom Izzo at Michigan State and Tony Bennett at Virginia. It is a variation of man-to-man defense with the biggest difference being off-ball defenders play in the gap instead of pressuring their player and denying the pass. Everyone except the player guarding the ball plays inside an imaginary line 16 feet from the rim also known as the pack line. As the ball moves around the perimeter, it is the responsibility of each defender to close out on the ball and aggressively pressure while the remaining defenders adjust their position accordingly to see both man and ball and prepare to help their teammates – 5 against the ball.

Cloud Security is everyone’s responsibility and while we are aggressively providing man-to-man defense on the active products, the rest of the team is continuously adjusting to find and fill gaps in the defensive strategy. We react to changing conditions and close out on threats while keeping business goals front of mind. 

The ephemeral and elastic nature of the public cloud along with software defined infrastructure and platforms provide an opportunity for service specific architectures. Trility utilizes two patent pending tools to help provide high quality customized security for cloud services: IronBench Compliance Navigator  and IronBench Cloud Config.

IronBench Compliance Navigator empowers organizations to develop highly customized compliance guidelines for products and services. Throughout the product lifecycle, IronBench Compliance Navigator uses standards and regulatory information updated as regulatory compliance laws and standards change to provide a solid foundation for product development teams.

IronBench Cloud Config is an enterprise framework and provides the source code for the entire implementation. Product teams can utilize a customizable secure framework based on industry standards and practices on which to build secure supporting infrastructure. Compliance Navigator helps you aggressively challenge the ball handler while Cloud Config supports the team by helping them adjust to changing product needs efficiently and securely working from a library of standards based templates.

No easy lay-ups.

Did You Mean DevOps or DevOps?

DevOps is another word starting to lose its meaning in today’s marketplace. Ask an Engineer and DevOps is a set of tools or programming languages to take code from the Developer, package it up, and promote it through environments to production. Ask a Product Owner and DevOps is a separate team of individuals maintaining the Continuous Integration/Continuous Deployment pipeline. Ask a Senior Manager and DevOps is a culture inside the organization to promote interdepartmental communication and breaking down barriers. Three opinions: a suite of tools, a team of individuals, or a new corporate culture.

More often than not when an organization is looking to solve problems with throughput from the product teams, a DevOps group is assembled to bridge the silos between various parts of the organization. Unfortunately, instead of bridging the gaps between the silos in the organization, a new silo is created around a set of new tools aimed at Continuous Integration and Continuous Deployment. Instead of connecting groups, the organization now has another team competing for precious budget, is bringing new tools and processes into an already complicated technical stack, and in the end the core problem still remains.

In the F5 State of Application Delivery report for 2017, DevOps was only selected by 20 percent of the 2,197 respondents as having a strategic impact on application delivery. Software as a Service (SaaS), Big Data, and Infrastructure as a Service (IaaS) in the public cloud were far ahead of DevOps in strategic impact for the organization.

Interestingly, overall, DevOps was selected as having strategic impact by just 20 percent of respondents. Among those in executive roles, DevOps was identified by only 17 percent, well below front-running SaaS (42 percent), big data (41 percent), and public cloud (IaaS) (39 percent). Among those identifying as having DevOps and cloud-related roles, DevOps took third place with 39 percent behind SaaS (44 percent) and big data (42 percent). This is in spite of evidence that organizations are engaging in at least the automation and orchestration aspects of DevOps.

However, according to the 2018 Open Source Jobs Report published by The Linux Foundation and Dice, DevOps skills (59%) are second only to Developers (72%) as the most sought after position. Organizations have a real need to solve operational throughput problems to get products from the napkin to in front of the customer efficiently. Simply having a DevOps group inside the organization is not getting the job done. Clearly there seems to be a disconnect between the strategic value of DevOps and the drive to continue to build a DevOps team.

Given all of the confusion regarding how DevOps is defined and the strategic impact to an organization, it is important to have a single definition communicated throughout the organization. 

At Trility Consulting, we believe the delivery of testable, secure, software to production on a regular, repeatable cadence is the responsibility of everyone on the team. There are no walls, there are no silos. It all starts with amazing Product Owners, Developers, and Delivery Engineers who are focused on delivering an exciting application development experience. Everyone on our project teams are dedicated to diving in and understanding how we solve business problems together. 

When you hear a member of the Trility Consulting team talk about DevOps we are talking about our commitment to the business problem at hand and delivering value to the clients we have the privilege to serve. As a team we are focused on delivery.

Don’t Forget the “V” in MVP

Minimum Viable Product, or MVP, is a common term used by businesses leaders and product owners to help drive quick, iterative, product development to get products released to market faster. The goal is to release just those core features necessary to put the product in front of customers to learn about customer needs and validate assumptions prior to larger investments in a new product. Release quickly, release often, and adjust the product based on feedback from customers.

Product teams today do a great job of focusing on the M, Minimal. Constantly asking the team and business stakeholders when new feature requests are made, “Is this a requirement for MVP?”, helps prioritize development efforts and keep the team focused on making a timely and relevant release. Business stakeholders on a regular basis can see the features being developed during frequent demos and can provide direct feedback which goes back through the same intake process grounded by the same question focused on releasing the MVP. When the cycle is managed by a proactive Product Owner, it can be an extremely efficient way to get ideas from a napkin at lunch to a product in front of customers.

Where Product teams struggle is with making sure the V, Viable, is taken into consideration as a team. Security, operational readiness, reproduceability, and scalability are all important parts of any product which helps validate the viability of a product. Unfortunately, in the race to production these items fall by the wayside and show up on the backlog. When the team does release the product and receive customer feedback, they’re often stuck in a challenging position of either picking up the items in the backlog tagged as After MVP or continuing to refine the product to keep customer engaged. As it should, the focus remains on the customer and meeting the business objectives for the product. The weight of the backlog eventually causes cracks in the team, cracks in the product, and a new round of questions for business stakeholders to consider regarding whether to refactor, rewrite, or sometimes, a new MVP to fix the problems from the previous MVP.

Continuous Integration, Continuous Deployment, Security by Design, Test Driven Development, Performance Testing, Infrastructure as Code — these are all terms many development teams are familiar with and actively promote inside organizations today. However, many of these items are the first things added to the backlog during MVP development when teams are racing against the clock. We need to do a better job as Engineers communicating to business stakeholders that each of these items are individually, and collectively, an important part of making a product viable.

We can still meet the needs of a minimal product by constraining the conversation in each case to the product being developed. The product may not have a need to support a thousand requests a second for the MVP, but we should ensure performance testing frameworks are in place and exercise the product on a regular basis so issues can be discovered early and often during the development process. The product may only require a small amount of simple infrastructure to be deployed to support the MVP, but the infrastructure should be built and deployed in code along side the rest of the product so as needs change the foundation is already in place to support rapid growth. The product may not have a requirement to support a security standard for the MVP, but the application should be built following a set of standard security practices and validated regularly with automated testing to support a growing customer base. 

Viable – the ability to work successfully

Product teams need to ensure when MVP is defined, the product’s ability to work successfully after release is front and center during the development process. Minimal helps you get to the first release; Viable ensures you make it to the second.