Hammer (and Sickle) Security Questions

March 7, 2017 - 4 minute read -
process

Getting compromised is a sure way to lose market cap and customers. Five questions provide the framework for a security-minded culture. Ask these first-pass security “hammer” questions to spur everyone’s critical thinking to guard your data, IP and customer information from being uploaded to Russia.

Business Risks

Companies quickly acknowledge security is important, yet simultaneously struggle to balance security with productivity. Hacks are not necessarily external or malicious–inadvertent sharing and accidental access leads to unintentional leaks.

A slowdown in productivity is immediately measurable to a startup’s velocity. Shortcuts in security accumulate fat-tail business risk–a metaphorical brick wall to your fast-moving startup.

B2C Companies are Judged By Quantity

B2C companies attract headlines around the number of users affected. Headlines often highlight the number of SSN, credit cards or bitcoin hacked. The average users may not appreciate the nuance of weak passwords security

B2B companies are Judged By Revenue Loss

B2B companies risk their entire customer base for adding business risk to their customers on top of the cost and time to mend relationships. While B2C is a game of large numbers, B2B startups face significant business risk by damaging a few very valuable customers that form the base of revenue. The good news – you will likely stay out of the news headlines, but pay significantly to keep your customers happy and quiet.

Hammer Questions

Security is a power and endurance sport won by expertise and pervasive cultural values. Automated and auditable process within every phase of the development life cycle maintain high integrity with low friction. As features, services and systems are created and evolve, a few intuitive questions empowers every employee and function to contribute without a debilitating loss of agility, trust, communication and innovation.

Answering the questions accurately may require domain knowledge or technical expertise. Asking and requiring answers builds a mindful team capable of navigating the security discussion.

Categorize Your Data

Is it sensitive?

Isolating sensitive data, services and systems into a radioactive zone away from all others allows your other data and systems to be more open for internal innovation and self-service. This technologically enforced separation frees employees from worrying “should we access” this data or system.

Your security policy explicitly spells out information security categories according to business value and risk, and the business roles and needs for accessing systems and data, even if you have the proper credentials.

If a system contacts the radioactive zone, or if data passes through the radioactive zone, it too becomes radioactive. Move it inside the zone.

Interrogate Yourself

Could we uploaded it to Russia?

Open and unmonitored egress is the easiest escape route for sensitive data and IP. Once outside company systems, your team loses the ability to monitor, evaluate and control the exposure. Blacklists are massively insufficient, but whitelists are also tricky. For example, an attacker brings his own AWS S3 credentials, bypassing your carefully controlled read/write IAM settings for company controlled buckets. Since S3 is on your whitelist, he copies client data into a personal bucket, and then from there to a server in Russia.

Your team must control all accounts and services on whitelisted IPs and domains

Can we download it and walk out?

Once data is off the server, physical removal is the second method of egress. Exfiltrating data via physical media, like a thumb drive or personal phone, or digital methods such as bluetooth, file share, or connecting to another network and uploading the data undetected, all become viable.

Restrict connections to the radioactive zone to stationary, physically secured hardware with rigorous administration, monitoring, encryption, and limited network access.

Can we access it without authentication?

Separate authentication (identity) from authorization (permission). Even non-sensitive data should require authentication, though every user may be authorized. Gone will be the days of asking who is running that query which is trying up the server? Ubiquitous authentication provides an audit trail for all access, and gives your team individual accounts to disable with surgical precision.

You would never share credentials, now would you?

Can we abuse it in combination with other systems?

The trickiest question–bring in your teams subject experts–is how the exposed services, systems, and APIs might be abused or used in conjunction with other systems to elevate privileges, access sensitive data or exfiltrate data from your radioactive zone. Radioactive services that are able to write outside the zone are likely exploitable, especially services like email, code review/differential tools, image processing, and logging all provide little input restriction.

Split these systems into radioactive only, and everything else.

Review

Your startup will put up meaningful resistance if all your sensitive data is

  • confined to your radioactive zone
  • cannot be uploaded to unauthorized destinations
  • cannot be downloaded to transportable or unauthorized devices

Additionally,

  • all systems require authentication
  • robust review and testing monitors possible paths of escalation and exploitation