Pinky Swear Security

No one in your organization gets to be clueless about information security.

This article was originally published on LinkedIn.

“We hire great people” is something we all hear companies regularly communicate.

How do you feel about a hypothetical company that believes the risk of an information security breach is low largely because they hire good people? In other words, their information security strategy is to hire good people and trust them individually to do the right thing. Maybe they even sign a paper pinky swearing they’ll always do what’s right.

Let’s say this hypothetical company houses some of the most sensitive data about you and your family or company that exists. Your information is passed around via email or attachments inside and outside the company. Information is even passed between teammates via chat tools sometimes. Said information is also accessible, editable and exchangeable between partner/vendor companies in the background. This data is unencrypted when stored (at rest) and when passed around (in transit).

Do you know about companies like this? Is this your company? Is a company like this minding your personal data?

While information security is everyone’s responsibility, it is first the responsibility of the company itself. Hiring great people does not alleviate, or defer, the responsibility an organization has to be compliant with information security policies, legislation and industry best practices. If we can’t trust a company to do the right thing, why would we value their brand?

Interesting Things We’ve Heard Through the Years:

  • “Our people, vendors, and partners do the right thing. That’s why we work with them. I don’t think we have anyone in the company who would abuse our customer data.”
  • “First, we must get product to market and prove the idea is viable. We’ll validate viability of our product by customer adoption velocity and demand for new features. If the numbers suggest customers want to buy and use our product, then we’ll figure out what security we need thereafter.”
  • “We’re going to wait and see if this policy/legislation has any teeth. If we start getting fined for non-compliance, then we’ll begin considering if, how and to what extent we need to invest in information security.”
  • “Our industry is not very interesting to most folks. We don’t believe our company, products or services are really a threat to anyone. And we believe the likelihood of being attacked or otherwise exploited is pretty low to non-existent. We’ll wait until it makes sense before investing in some of the information security measures we hear about. It all sounds so expensive anyway.”
  • “It is actually cheaper for us to pay the fines.”
  • “Our customers don’t know any better.”

“Security first” or “security by design” is a choice. And it must first be the choice of the governing board and company leadership before it will become a reality for employees, partners and vendors. If it is not a top-down, constantly communicated, verifiable expectation, it does not exist.

7 Steps to Become a Security-First Organization

1. Internally declare that your company will become “security-first”

When initiatives start at the bottom of the company, they risk dying out due to lack of energy, resources, and attention. Sometimes they risk actually burning up the people trying to get the changes implemented as hope turns into apathy. It is the proverbial “fight against the man.”

As a Board or Senior Leadership of a company, what is important to you is important to the company. If it isn’t, that is a different problem altogether.

For a company to become a security-first focused organization, the declaration of importance, direction, and expected actions must come from Senior Leadership first.

An example “From the CEO” communication:

“Folks, effective immediately, we will put security, privacy, and compliance first in our daily operations. This means with every product, service, interaction, and communication, internally and externally, we will consider what must be secured, how it must be secured and under what conditions we must secure it – data, systems, teams, company and client interests inclusive. It is not a task to accomplish and be done. This must be our DNA. It must be our daily lifestyle. And it will take time to get to a proper baseline of competency and time to maintain, evolve and increase it.

From this day forward there will exist training expectations that must be pursued and accomplished monthly, quarterly and annually. Look for them in your Learning Management System (LMS) assignments. All roles, titles, and capacities. No exceptions. Me included.

And from this day forward you will see our CISO take a more prominent role in defining our pursuits, our strategies and validation of our compliance readiness. We as a leadership team choose to proactively educate our teams, protect our assets and behave in a manner expected by our Founders and those who have come before us to build this great company.

Thank you for your commitment to being the best.”

Top-down declarations become realities.

2. Determine what industry regulations apply to your company

Information Security / Regulatory Compliance is a career. And there is a shortage of people who do this type of work. Find them. Hire them. Leverage them. Knowing what you must align to will save you money. Knowing what you need not align to will also save you money.

There are quick determinants to flush out directions, follow-up actions, and investment. The road will not be small, nor easy; though this list will help point you in a direction of what matters, when it matters and to what extent.

  • In what industry do you operate?
  • Is your business localized to your state only? Your country only?
  • Do you do business internationally? What countries?
  • Do you exchange money with customers?
  • Do you ask for and store personally identifiable information?
  • Are you working with non-governmental organizations? Charities? Governments? Militaries? Public companies? Private companies?
  • Have you failed any previous compliance audits?
  • Have you been fined by a third-party organization for non-compliance?

3. Determine what industry best practices will help your company

You may discover your information security folks want impenetrable castle walls, which eventually mean your employees are unable to use the bathroom in the name of security. An extreme.

You may also discover your engineers want the freedom to use anything at any time for any reason in the name of innovation, digital transformation or being competitive. Probable.

And your business unit leaders? You’re expecting them to grow the business, delight the industry and client base. They want to do whatever is necessary and appropriate to meet the goals expected of them as well.

Security, innovation and growth are not mutually exclusive. They must be collaborative and it will require constant, purposeful and involved leadership. Otherwise, it is just theater.

Regulated industries communicate best practices and compliance expectations, which makes it easier to know what matters and what doesn’t. Where your time will be spent is determining how tightly to dial up the security requirements on your operation and how they will impact friction, flow, deliverable velocity and value from the organization.

Unregulated industries still have communicated best practices and compliance recommendations. In the absence of all knowledge, ask the following questions of your Chief {Information Officer, Information Security Officer, Product Officer, Technology Officer}:

  • Against what information security / regulatory compliance standards must we be measuring ourselves?
  • How are we training our people to be predictably and repeatably compliant with these expectations in our everyday lives?
  • How can we regularly prove that what we expect is actually being employed?
  • How do we culturally make security and compliance a behavioral assumption versus a Learning Management System (LMS) assigned task?

4. Implement role-based security awareness training

No one is exempt from information security. No person, role or title. Like leadership and teams, security is a “we” endeavor.

Not all roles in the company have the same requirements. Some roles are specialized while others are more general. Below is a simplification of this idea.

Specialized: Information Security folks may say higher-level things like confidentiality, integrity, and availability. They may roll out policies, procedures and learning courses while facilitating internal and third-party audits. They’ll even be discussing Plans of Actions & Milestones (POA&M or POAM) items resultant from audits. They’ll need to know frameworks, behaviors, implementations, monitoring methods, and reaction/response ladders and industry standards like NIST-CSF, PCI-DSS, HIPAA and so many more.

Specialized: Engineers who focus on infrastructure, networks, data, and software technology stacks need to know about the what, but more importantly, they need to understand the why and how as they do their work. For example, data encryption at rest and in transit, authorization, and authentication, securing failover infrastructures, hybrid cloud solutions, bring your own device security, separation of duties, least privilege and need-to-know principles. There is more than one way to implement any one of these concepts and Engineers need to know them.

Generalized Awareness: Everyone else.

Figure 1. The diagram above demonstrates at a high level how role-based security awareness training could be rolled out and that everyone is a part of it. No one ever gets to be “clueless.”

5. Include the information security role in solution delivery teams

Whether your company calls them Scrum, Strike, AgileProduct or Project Teams, the team construct used to deliver an idea from inception to conclusion often contains multiple roles and therefore multiple people.

In order to become a security-by-design or security-first company, your teams must be shaped to enable the desired outcome. Which then suggests that an information security/regulatory compliance expert must be included from project inception through the course of the project.

This conversation is less about the recipe for roles and teams and more about the desired outcome. Context-driven teams influenced by desired outcomes.

Strike Team Delivery Model
Figure 2. Trility’s preferred team pattern is the use of a Strike Team that always includes an Information Security/Regulatory Compliance expert involved throughout the lifecycle of the project or product. While we tend to construct teams based upon the desired project outcomes, we include an Information Security expert on the team by default.

If the information security people are technical, they may be helpful with design, development, and implementation every step of the way, all day every day. If the information security people are non-technical, they may be more aptly leveraged in a principle-based guidance role during iteration planning, stand-ups, demos and reviews to ensure the project continues to move forward between the fences.

Either way, there must be a full-time champion for the company and clients in terms of privacy, compliance and best practices to achieve the desired outcome.

6. Determine how you will proactively test your ongoing compliance

There are any number of methods to test ongoing compliance. Blind trust. Word of mouth. Internal (infrequent) manual inspection. Third-party annual inspections. Or continuously through automation.

Our typical practice is to identify what attributes of compliance must continually exist, automate those attributes into a series of tests that are called, executed, logged and tagged every time new infrastructure and applications are built. When non-compliance happens, alert someone (as shown below). Otherwise, keep moving. We have some examples out there in the ether for you to thoughtfully consider.

Automated Security Tests
Figure 3. The diagram above shows how you can build-in automated security/compliance tests such that every build now has the capability of logging activity, events, alerts and compliance status.

7. Attach quality and compliance tools to the delivery pipeline

Continuous delivery pipeline behaviors are not new. Wide-spread awareness and adoption of new concepts takes time to expand across industries, companies, leaders, and teams. As more companies implement continuous delivery principles, more of the things many companies used to exclude because it took too much time, or did perform, but manually in arrears and infrequently, will be automated providing real-time information radiators.

Look for vendors and tools that are API-driven, have a great online community, openly available developer and administrative documentation, as well as, active tool support. These tools enable you to perform automated analysis-refactor loops now versus waiting until later and hoping for the best. It is worth your money to know your risk exposure now.

Continuous delivery pipeline with security built-in
Figure 4. This diagram illustrates wherein the continuous delivery pipeline predictable, repeatable and auditable security behaviors may be baked into the solution delivery process now versus waiting until later.

Hire great people. Cast a vision, communicate desired outcomes, define clear objectives, give them the resources to be successful, give them rules of engagement and stay involved.

Great people make mistakes. And even great people some times do not know what to do. Security frameworks help mitigate oversights, mistakes and provide guidance when people are in new, different and complex situations.


I drink a lot of caffeinated coffee and tea. And I’m on airplanes a lot. Drinking coffee and tea. I’m making a commitment to write more articles in 2020 – and increase the number of speaking engagements at which I drink coffee and tea. It is material we discuss every day at Trility and with our clients. It is material that you may find helpful as well. If you’d like to keep informed, and even interact, please connect or follow me on LinkedIn. Or we can send you an email

We are also always looking for system thinkers to join us – those who can see the larger landscape and do the work as well. If this resembles you, email us.

7 “Not Easy” Steps for Securely Using Data for Real-Time Decisions

ARTICLE | A step-by-step roadmap for taking control of your data, securing it and making it meaningful to everyone at the same time, in the same way.

Originally published on LinkedIn on Oct. 22, 2019.

Companies have data in many places. And many companies do not know what data they have, where it is stored, who and what has access to it, the trustworthiness of the data or how to organize it in a timely manner into decision criteria for leadership teams.

The easiest way to know if what I’m saying is truth is to ask someone on your technical staff to provide you an asset and access inventory. Ask them the following:

Tell me:

- All software applications used in the company
- All places data is stored in the company
- All hardware used in the company to host, edit and manage both
- Who/what has access to these things and with what levels of power

And

- How the data is secured in transit and at rest

Give them one business day. Their reaction will reveal your truth.

Running a company minimally requires two things: knowing where you want to go and having access to timely, trustworthy data that will guide your journey. This article discusses the data aspect only.

And as you may already hope, suspect or know, addressing unsecured, unmanaged, disparate applications, data and permissions is a solvable problem. Accessing one view into your company is also solvable. Let’s look at the plan.

1. Find Your Data

Inventory all software applications and data repositories inside and outside your company, as well as, anything interacting with or exchanging data with your applications and repositories.

2. Determine The State of Your Data

What is the technology collecting, managing, editing your data? Where is it hosted? By whom? Is it good, questionable or corrupt data? Who and what has access to it? What are they doing to the data? Who is managing the security and sanctity of the data? How do you know you can trust the data? Is the data current and with what frequency?

3. Secure your data

Is the data managed via role-based permissions or is it wide-open for too many people and systems to manipulate, extract and exploit? Is it direct-connect? Copy-paste? Batch-uploads? API-accessible? Is it secured while at rest? Is it secured while in transit?

Think your company not likely to be attacked, corrupted, ransomed or otherwise exploited? Consider your brand value, consumers, privacy laws and bad company press. Do people trust your brand today? Will they after a breach?

4. Establish a Common Data Format

When data originates from multiple data sources, the structure of the data is usually non-uniform. The first step is to understand the current structure and state of all data at the origination point.

The second step is to determine to what Common Data Format (CDF) all data will be funneled and/or otherwise re-organized. In other words, if your company’s growth strategy has been through Mergers and Acquisitions, you likely have many data stores with similar types of data, but with different states of sanity. If you want one view across all of these data stores, words must have the same meaning for all instances of all data. Establishing the same meaning for all similar instances is “normalization” or “establishing a Common Data Format.”

Many to one.

Only after there exists a common data format are you able to see, understand and make decisions that confidently and consistently take into consideration all parts of the company.

Establish a Common Data Format

5. Extract, Normalize and Put

When you understand all places from which data originates and have a CDF, your teams are then able to write predictable, repeatable and auditable methods of extracting, normalizing and putting data into your new, single source of truth.

To be clear, the methods of extracting data, normalizing data and putting data must be predictable, repeatable and auditable. And the structure into which all data is put is itself the CDF. Anything less and you will simply be creating a new mess that must be managed on top of your existing ecosystem — whatever the state.

6. Pull Data Predictably

Now that you’ve made the effort to ensure all data, from all locations, is secured and normalized, protect it. This means there must exist a predictable, repeatable and auditable manner by which applications, systems and companies access your data. Notice I didn’t say people.

To access data from the single source of truth, there must exist predictable, repeatable and auditable set of actors, permissions and activities. If there is variability in actors, permissions and activities, it will no longer be a single source of truth.

Require anyone or thing that wants access to your data to follow your rules. Non-negotiable. This includes people in Mensa, people with twenty years of tenure who have been there since the company started, the CEO’s nephew and your mom.

Your single source of truth is special. No one who wants access to the data is special. Despite what their mom told them when they were young.

7. Use Your Data to Inform Your Decisions Dynamically

Attach reporting solutions. Attach streaming solutions. Attach elastic search. Attach dashboards. Follow the rules. Enjoy peace.

Now you can trust that your data has integrity. You can trust it is secure. You can trust your data is predictable, repeatable and auditable. You can trust your company has one message.

And you can trust that you know all applications, repositories, data management and security behaviors, actors, hosting solutions and reports are something upon which you can bank your company’s reputation.


If you would like to take control of your data, secure it and make it dynamically meaningful to everyone in your company, the teams at Trility help companies solve these challenges with a focus on predictable, repeatable and auditable behaviors. Email us at forthejourney@trility.io.

Pack Line Cloud Security

Cloud Security is everyone’s responsibility requires aggressive defense.

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 fifth-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 of tools, services, and seemingly infinite combinations organizations can utilize to solve business problems.

Playing Cloud Security Defense

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 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 – five 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.

Don’t Forget the “V” in MVP

Security, operational readiness, reproducibility, and scalability must validate the viability of a product.

Minimum Viable Product, or MVP, is a common term used by business 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, reproducibility, 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 customers 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 alongside 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 and securely.

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.