I thought I would show you 3 metrics that I have seen in insurance intake forms. These should help you think about what you might have to put in place in order to satisfy their requirements, but also what you might want to measure.

The average time it takes you to triage endpoint incidents. Top performers can respond to these incidents under 30 minutes. Worst performers will never be aware of anything. To measure this, you need some kind of way to monitor the laptops you provide employees with. You also need someone to operate the monitoring tools and an incident response plan.

The number of users with persistent admin credentials. In a perfect world, you would only get admin access for documented operations, for pre-established reasons, at a pre-established time. But in the real world, some people end up with permanent admin access. Are you tracking this?

The time it takes you to deploy high priority patches. Modern tools used by adversaries can ingest data about new vulnerabilities in a short amount of time. The speed at which you apply patches should not be left to chance. You need to know that new patches are available, what impact they have, and when you can schedule time to apply them. This should be measured in hours or days, not weeks. Remember that patching can disrupt operations in unknowable ways.

You effort it takes for you to find these numbers is a good sign of the maturity of your security program.

Offer the option to run isolated instances of your solution. Multi-tenancy is cheap, but the guarantees it offers are hard to prove. How do I know you designed permissions in your database correctly? If my instance is isolated, it's easier to believe that other tenants won't have access to my data.

Encrypt the data using your client's encryption keys. The only way I can be sure no one in your team is snooping on my data, is if I control the encryption keys. Let me send you a public key, and give me control over the mechanism by which my data is encrypted.

Offer role-based authorization from the start. If you want me to onboard new users on your platform, I need to know that I will be able to manage permissions properly. I don't want to end up with everyone having access to everything.

Implement single sign-on using industry standards. I don't want my team to have to remember another password. Make it possible to provision users from a corporate user directory. I want to be able to re-use the identity and access management work I've invested in already.

These features are good enough to make you a category of your own. If I'm comparing potential partners, you will stand out every time. Make sure that these features are available, that they work (!), and keep them free, forever.

The framework is divided in 2.

The baseline controls are the countermeasures you might want to put in place.

Once you've scoped your program, there are 41 countermeasures you can leverage to control different risks.

The organizational controls are ways to scope your risk treatment plan. The document says:

The goal [of the organizational controls] is to help an organization determine whether the baseline controls are appropriate for its circumstances.

The 7 organizational controls can shortened to:

1. List the assets in scope
2. Identify the main threat
3. Assess risk
4. Assign responsibility
5. Identify the budget required for IT security investment
6. Identify the staffing level required for IT security
7. Commit to progressive improvements

And it really comes down to these 4 steps:

1. Determine what information technology is in scope
2. Determine the value of information systems and assets
3. Confirm the cyber security threat level
4. Confirm the cyber security investment levels

Don't skip these controls. Scoping your security program early in the process will help you avoid spending time on the wrong thing. These controls will save you time and energy.

Collect everything

Pull quotes from Slack, take screenshots of websites, and record audio clips. Dumpster dive in your Downloads folder and save all of these PDFs you've been collecting. Sometimes you won't have time to write good docs, but you might still be able to put together a resources page.

Put it all together

Choose a single location for your documentation and commit to it. Make it easy to put stuff in it, but hard to delete anything.

Create some kind of index

Create a central document that links out to everything else. Make sure to keep it up to date at all times. Your index is your treasure map. You will use it to make sense of your mess.

Look at the stats

People in your team will refer to the same documents again, and again. Notice which pages are visited more often and find out what they have in common. Do more of what works.

Create templates

Make it easy to create more documentation. It's easier to fill out a template than starting from scratch every time. Use your popular documents as example.

Delete as you go

We accumulate old stuff real fast. Wrong information is worst than none. Don't hesitate to nuke what you will never use again.

Short is fine

Sometimes just a few sentences will do. People don't read. Make your point, and move on.

In short

1. Collect everything.
2. Put it all together.
3. Create some kind of index.
4. Look at the stats.
5. Create templates.
6. Delete as you go.
7. Short is fine.

1. Understand legal & compliance requirements. Surround yourself with experts who can help you understand the nuances.
2. Have a business continuity plan. Consider how you plan to continue servicing your clients during a crisis.
3. Put in place core policies. Make it clear what the boundaries are and what you expect of team members. Take the time to understand how these rules will affect team dynamics.
4. Maintain an asset inventory and assign ownership. Distribute the management of system and data risk to their respective business owner accross the organization.
5. Reduce your attack surface. Consolidate tools, configure data lifecycle, deprecate old systems.
6. Control access between trust zones. Use simple role-based models, assign roles according to responsibilities and leverage native solutions.
7. Model the relevant threats. Consider your own mistakes, abuses of trust and third-party risk.
8. Rehearse your incident response plan. Make sure you have a reliable secondary communication channel, run your call tree and get clear on how to classify and react to incidents.

In short, the standard gives you the structure needed so you can go back to building your product and trust that you are staying on top of your cybersecurity game.

Security projects can improve all kinds of important business metrics. But ambitious initiatives that try to fix everything at once rarely succeed.

Instead you find ways to improve a lot of small things.

They don't get in your way, and you benefit from the power of compounding.

Split your big improvement projects into smaller chunks and do a lot of small things.

It has many goals:

• Improve portability and continuity of health insurance coverage.
• Improve access to long-term care services and coverage.
• Simplify the administration of health insurance.
• Promote the use of medical savings accounts.

But the one of interest here is:

• Combat waste, fraud, and abuse in health insurance and health care delivery.

Title II is called "Preventing Health Care Fraud and Abuse". It intends to protect the security and privacy of Protected Health Information, or PHI. For that, it includes provisions (rules) for Privacy, Security, and Penalties.

This post won't cover the whole range of businesses that have to comply with the regulation. It's aimed at startups who's product design involves them using PHI.

Who's responsible for what?

HIPAA is regulated by the USA Department of Health's Office for Civil Rights (OCR).

There is no official HIPAA certification. This means you can choose to self-assess or work with a third-party.

There are three roles modeled in the act:

1. Covered Entities - A health care provider who transmits any health information in electronic form. This would be users of your platform.
2. Business Associate - An entity that provides services to, or performs certain functions involving the use or disclosure of PHI on your client's behalf. This is you, the apps you use, and your cloud service providers.
3. Subcontractors - An entity to whom a business associate delegates a function, activity, or service.

A covered entity may be a business associate of another covered entity.

You and your clients have these responsibilities:

1. Provide records and compliance reports.
2. Cooperate with complaint investigations and compliance reviews.
3. Permit OCR to access anything required to help them figure out if you are compliant. This includes facilities, books, records, accounts, and other sources of information, including PHI.
4. Ensure you implement and maintain the systems needed to safeguard PHI

You and your subcontractors are liable for non-compliance with HIPAA.

What are my responsibilities in case of a breach?

TLDR: You have to be aware that a breach occurred, and report it as soon as possible. Also, people can file a complaint against you, which the OCR can investigate as much as they want. Your clients also have obligations. It's in your best interest to educate them.

Your clients must provide notification of the breach to affected individuals, the Secretary, and, in certain circumstances, to the media.

You must notify your clients if you, or own of your suppliers have a data breach.

You must provide notice to clients within a reasonable delay and no later than 60 days from the discovery of the breach.

You must provide your clients with the identity of each user affected by the breach and any other available information they need in their own notification to affected people.

You have the burden of demonstrating that every required notifications has been provided or that a use or disclosure of unencrypted PHI did not constitute a breach.

You must maintain documentation that all required notifications were made, or documentation to demonstrate that notification was not required.

You do that with one of:

1. A risk assessment demonstrating a low probability that the protected health information has been compromised by the impermissible use or disclosure.
2. The application of any other exceptions to the definition of "breach."

Your clients must have in place written policies and procedures regarding breach notification, they must train employees on these policies and procedures, and they must develop and apply appropriate sanctions against workforce members who do not comply with these policies and procedures.

You have 60 days to notify affected individuals, the OCR, and any other relevant people.

If your breach affects 500 or more people, OCR have a breach portal where they are required to shame you publically for 24 months. At the time of writing this post, there are over 800 entries in that list.

A person who believes one of your clients or you are not complying with the rules, they can file a complaint with the OCR.

An investigation can include a review of the policies, procedures, or practices of you or your clients, and of the circumstances regarding any alleged violation.

What are the costs for non-compliance?

Violations can incur fines between $100 and $50,000. Fines can add up to a maximum amount of $25,000 in the best case, and $1.5M in the worst case.

Factors that are considered to determine the maximum amount include:

• The number of individuals affected
• The time period during which the violation occurred
• The nature and extent of the harm resulting from the violation
• Your history of prior compliance
• Your financial conditions

Which really comes down to asking the following questions:

1. Did you make a reasonable amount of effort?
2. Were you, or should've you been aware that a breach occured?
3. Was the breach a result of willful neglect?
4. Have attempts been made to correct the violation?

What are we protecting?

Individually identifiable health information.

The transactions included in the regulation might give you some insight into where to look for PHI.

1. Health care claims or equivalent encounter information.
2. Health care payment and remittance advice.
3. Coordination of insurance benefits.
4. Health care claim status.
5. Enrollment and disenrollment in a health plan.
6. Verification of eligibility for a health plan.
7. Health plan premium payments.
8. Referral certification and authorization.
9. First report of injury.
10. Health claims attachment uploads.
11. Health care electronic funds transfers (EFT) and remittance advice.
12. Other transactions that the OCR may prescribe by regulation.

The transmission of information between two parties to carry out financial or administrative activities related to health care.

What are the Security and Privacy requirements?

You are responsible to ensure the confidentiality, integrity, and availability of all PHI you or your clients create, receive, maintain, or transmit.

You must protect it against any anticipated dangers to its security or integrity.

You must protect it against any anticipated uses or disclosures that are not permitted or required.

You must ensure compliance with these requirements by your workforce.

In deciding which security measures to use must take into account the following factors:

1. Size, complexity, and capabilities
2. Technical infrastructure, hardware, and software security capabilities
3. The costs of security measures
4. Probability and criticality of potential risks to PHI

Individually identifiable health information should be protected with reasonable administrative, technical, and physical safeguards to ensure its confidentiality, integrity, and availability and to prevent unauthorized or inappropriate access, use, or disclosure.

The safeguards described in the regulation text look like what you would expect from a standard security management system. They have three categories: administrative, physical, and technical.

The HITRUST framework provides mapping from these controls to other frameworks like NIST and ISO27K1.

More information

Most of the information in this post comes from the Combined Regulation Text of all the regulatory standards.

You can also read the Health Insurance Portability and Accountability Act of 1996 on the U.S. Department of Health's website.

Their volume over time correlates with a probability of being exploited.

So you want to fix your bugs at a reasonable rate.

But first you have to figure out what a reasonable rate is. And make it explicit with every stakeholder in your contracts.

If you then invest in a reliable way to measure that rate, you can free yourself from operations to think at a more strategic level.

Your job is not to not make mistakes. It's to fix your mistakes at a reasonable rate.

But recently, I started writing five days a week. I used to find it hard to sit down and write. Now, I'm excited about finding out what I'll end up creating.

Instead of forcing myself to do something I didn't want to do, I adopted a practice. It's basically the same thing, but in one case I experience empowerment instead of drudgery.

Now, I know exactly how much work I have to do to reach my goal.

Writing 0 days a year has a clear outcome: you will see no benefit from the written word.

Writing 260 days a year has a clear outcome too:

1. You will get better at it.
2. Other people will notice.
3. It will impact your bottom line.

Adopting a practice comes with a baseline for the results you should expect.

This applies to security too. You have to balance discouraging and encouraging behavior.

It gets annoying to always hear "You're not allowed".

But following a practice creates a strong sense of competence.

It's easy to measure. You can count the number of days you followed through.

There are no numbers to game. You only need to keep your ratio close to 100%. You can also measure your winning streak, the number of consecutive wins.

It's great for forecasts, because with regularity comes certainty.

It emphasizes capability instead of vulnerability, which is much more empowering.

And it means investing in people, not bureaucracy.

Here are some answers I'd be looking for when hiring for a pentester or a cybersecurity analyst position:

1. Can I trust this person to be autonomous and do the work without needing too much supervision?
2. Will this person be a good fit for my team?
3. Can this person understand the impact of their findings on my client's business?
4. Will this person be able to write clear, consistent and error-free reports?

To answer these questions I'm gonna make assumptions based on the information you provide me.

The more you speak in terms of outcomes you have achieved, and the more those outcomes match those I am looking for, for my team and my client, the more I'm gonna be curious and interested in talking to you.

At scale, the quality of your models will improve by orders of magnitude.

When investigating a security incident, access logs help you understand what happened when, and who did what. The moment that two agents (a user or an application) share an identity, you lose the non-repudiation property.

When reviewing access permissions, look for shared identities. The easiest way to find out if an identity is shared is if two people share a password.

Chances are that your environment has a shared admin account and a few shared service accounts. Ideally, you should avoid sharing credentials. But sometimes it's a necessary evil.

If you can't, make sure that your system keeps a record of who did what. Your security alerts will become more relevant and your incidents will be easier to investigate.

Some of them (ie: Bitwarden and Lastpass) store data locally. You can sync the directory to your favorite file hosting service.

As with any backups, make sure that you have a backup restoration procedure, and that you test it regularly.

They might be trying to figure out what rules you put in place and how you make sure that people follow them. Or they might be trying to add friction in the sales process.

But the goal of a policy is to reduce risk by communicating clear rules to staff members.

It's not just the document, it's the organizational change that comes with it.

Asking an intern to write your rules for you might help you sign that contract tomorrow, but it might line you up with more trouble down the line. Bad rules create more problem than they solve.

When someone asks you if you have a given policy in a security questionnaire, tell the truth. It's the best policy.

If you always kept one side of them blank, you could count on them to keep your information private. You know you could always just flip them over.

Standards give you assurance in two ways:

1. They give you a description of what to expect. Flipping over sheets of paper hides private information.
2. They give you something to verify. There shouldn't be anything written on the back of sheets of paper.

By following standards, you stay consistent. And by staying consistent, you make it obvious when something requires your attention.

A value-stream map models the value proposition derived by the organization's customers. With these maps, you can follow value flowing across the company to identify and remove waste. Waste of time, of energy, of attention.

Value stream mapping happens to be useful in information security too.

If you follow value, from its creation to its capture, you can identify every IT system involved. It's like a treasure map.

We often think of information security in terms of downside protection.

You reduce risk by bringing potential threats under control. You reduce costs by making sure you don't spend more than required.

Problems become easier to identify. You can keep track of and fix them before they become too big.

But when infosec listens to the needs of the business, other subtle benefits becomes clearer. Managing information systems optimizes opportunity.

You facilitate business deals by making sure documentation is up to date and reliable. You increase productivity by making whole systems visible and by automating tasks. And you increase trust with the absolute confidence that you know where you are, and you know where you are going.

But first, it needs to account for incidents of varying severity. This implies that you need some kind of standard way to rate the severity of an incident. I have seen people struggling with this and honestly, the answer is to keep it simple.

5 levels of severity divided in 3 tiers:

Tier 1. Go to red alert

Impacts production.

• SEV1: Catastrophe. Most critical systems affected.
• SEV2: BIG problem. 1+ critical system affected.

Tier 2. Go to yellow alert

• SEV3: Significant issue. Could affect critical systems soon.
• SEV4: Definitely a problem. Stay vigilant.

Tier 3. Informative.

• SEV5: We can fix this later. Managed in bug tracker.

Remember that you want 100% of your staff to understand this completely. So keep it simple.

CertiK is one of the well-known blockchain security audit firms. I took a look at their report "The State of DeFi Security 2021" this morning. I thought I'd share some insights.

Centralization issues accounted for about 16% of their findings. These are security vulnerabilities introduced at the design stage, meaning that they can't be solved by "fixing" code. They're usually a result of contract developers including functions that give them some control over some aspect of the system.

Centralization issues lead to vulnerability to attacks we were familiar with before web3, such as the theft of private keys.

Controls to compensate this kind of design decision include protecting privileged action with a timelock, using a multi-sig wallet, and delegating the authority to a DAO.

Timelocks delay privileged actions to give operators time to react to unexpected events. Assigning privileged roles to a multi-sig wallet reduces the risk that a private key compromise endangers the whole project. And delegating authority to a DAO distributes that authority over a group.

The report identifies 4 more commonly identified vulnerabilities:

1. Lack of event emission
2. Unlocked compiler version
3. Lack of proper input validation
4. Reliance on third-party dependencies

You can read the full report on CertiK's website.

But sometimes you need to verify that third-parties are respecting the standard you expect. Or someone might abuse your faulty assumptions. You will expect things to go one way, until the whole world goes upside down.

For example, in the 2020 Balancer hack, the Balancer smart contracts didn't have any bugs. It was assumed in the design that tokens in liquidity pools followed the ERC20 standard. But tokens with different characteristics ended up in there. There goes $500K.

If the assumption supports security properties, confirm that it holds true before leaning on it.

Security controls can involve a measure of imposition, and of voluntary participation.

Some things you can't control.

You can ask employees working from home to follow your rules, but you can't enforce them all.

Which leaves you in a weird position. Because you have rules, and you do want them to followed.

It's not that you want to protect your company against your employees. It's that this trust relationship you are building with them can be abused, and not only by them.

You have obligations towards your customers. You have custody over their data, over their private information.

If an incident were to happen, you want to be able to keep a straight face. You want to know that you put a reasonable amount of effort in protecting what's theirs.

We put so much emphasis on preventive controls that we forget that it's only the tip of the iceberg.

Deterrent controls help discourage rule breaking. And detective controls help identify an issue where preventative controls have failed.

Together, they help you compensate for the absence of preventive controls.

Draft a clear, concise policy that explains the rules you want to enforce. Communicate about this policy and have people sign it. Keep a log of the actions you are trying to control. Review those logs to identify any discrepancy.

When you can't prevent, detect.

They break and need to get fixed. Sometimes they need to be replaced.

It's the same for automation, integrations, and custom software.

If you account for the cost of ownership, you might be better off doing it by hand.

What seems like a technology investment could end up becoming a liability.

People regularily get scammed through this channel and the total amount of value lost sounds ridiculous.

To avoid getting spammed/scammed, you can toggle a switch in each-individual-server-that-you-join's privacy settings. The label reads: "Allow direct messages from server members".

This option is turned on by default.

Discord PMs probably had to make a trade-off between usability and security. I'm not sure.

But you can't avoid this decision. You always have to pick a default setting.

But it doesn't mean that you don't get to have any.

There are a few options available to you. One of them is the decoy. It's a trap that alerts you when something is not supposed to happen. Big companies have products that let them generate these on-demand. But if you're just getting started, you can keep this minimal.

Decoys work a bit like analytics trackers.

You put some kind of dynamic content, like a tracking pixel, in a document. Except the document looks like it contains something private or valuable.

You put the document somewhere you assume is protected. If someone interacts with it, you know they might be up to no good.

It doesn't have to be a document. It could be an email in an inbox, a usb key in a vault, or an API key on a developer machine.

You don't need that many. Focus on a few key locations.

Make sure that someone is responsible to monitor these alerts, and that they have a plan of action in the event that one of them is triggered.

For little to no budget, you'll have an alert system that works for a good portion of intrusions.

You already keep track of bugs with an issue tracker, and of threats with a threat model. Maybe you already track the progress of your security capabilities. Or maybe you should.

Why would you want to manage your weaknesses?

Capabilities are made of two things.

1. Tools - Servers, apps, dashboards, command-line utilities. The stuff.
2. Practices - The things you do. The actions that shape culture.

You develop capabilities so you know how to adapt in the face of change.

You see the bad thing coming. You react at the right time. You recover without breaking a sweat.

Track the maturity of your patching skills, not the number of bugs in your dependencies.

And we're always the ones with the bad news. Always bringing up problems, or issues, or dangers, or weaknesses.

People always ask us for exceptions. And we get in their way. All the time.

Don't let us tell you "no". Don't let security slow you down.

Just make sure you know how safe it is to go that fast.

The internet is an adversarial place.

Everything is lava.

It's the same with security incidents. You could take the hit, pay the price, and move on. Or you can use this opportunity to self-reflect. "What decisions did we make that led us to this outcome?".

These discussions won't happen on their own. Our natural tendency is to point fingers and blame each other. That's why you need to decide what you will do before the bad stuff happens.

You can become a disorganized mess, or you can become a learning organization. It's your choice. But you don't get to have both.

When you put that water bottle in your luggage, you want to know if your (paper) passport is in there.

You want to prevent the water from spilling out of the bottle and into your luggage. So you put it in a plastic bag.

The plastic bag is not water proof, so you want to be aware of what's going on in there. And you want to react before the water comes out of the plastic bag.

You also want to know you will to react the right way when that happens. This depends on you understanding what's at stake. There's a valuable document in there, and it's vulnerable to liquids.

In the worse case, your passport is unusable. You might need to replace it.

In the most probable case, your passport is fine, but you won't have water during that meeting. You might need to get another drink.

We don't seem to like thinking through scenarios like this. Systematically, I mean. Maybe it reminds us of our anxious ruminations. I don't know. But this is what assessing risk can look like. It doesn't have to be fancy.

You should be able to build the whole system with a single command.

If you don't have this yet, make sure you get it done before the contract with your security auditor starts. It will save them time which means more time to find bugs and more bang for your buck.

Start with a spreadsheet

There are many software tools you can use to manage your inventory. But when you're just getting started, deploying or registering for a new tool can add unwelcomed complexity. We are trying to reduce complexity.

This is why I recommend starting with a simple spreadsheet. Pick the software that your team has defaulted to, it doesn't really matter which. At this point, we want to make sure the work has started.

Maintain a list of asset types

Give each item in your list a category. At some point, you will start having a detailed enough inventory that you can start analyzing it and gain valuable insights.

Here is a list of asset types you can use to get you started:

Organizations and people:

1. Business partner
2. Supplier
3. Stakeholder
4. Employee

Data:

1. Secret (API keys, tokens, etc)
2. Private key
3. Configuration file
4. Source code
5. Regulated data
6. Customer data
7. Logs
8. Document
9. Data stream (Video, audio, etc)

Systems:

1. Cloud account
2. DNS server
3. Database
4. Endpoint (Server, desktop, laptop, phone)
5. OS
6. Network
7. Harware security module
8. Runtime
9. Web service
10. Tooling
11. IP address
12. Domain name

Is it mission critical?

For every item in your list, ask yourself the question: "Is it mission critical?". Maybe someone depends on this to do their work. Or maybe it supports the main service you provide. How long would it take for someone to notice if it went down or was unavailable? Identifying critical assets is crucial for your business continuity plan.

How sensitive is it?

Your asset list will contain data and systems. Is that data confidential? Does the system contain or process confidential data? Just how confidential? To determine this you will need a classification system. I like to use a simple 4-tier: Secret, Confidential, Private, and Public.

You should use the same scheme that you use to control documents.

Does it process private user information?

Privacy regulations like GDPR in the European Union make it mandatory to identify systems that process private user data. By being pro-active about this and adding this dimension to your inventory, you will avoid duplicating work in the future.

Where is it documented?

Documentation of different systems and datasets can easily get out of hand. Use a column in your inventory to note where the documentation specific to each item can be found. I like to maintain a list of documents in a different tab and reference that tab in each row using "Data Validation" in Google Sheets.

Assign ownership

Last but not least, make sure that you assign an owner for each of these assets. The owner will be responsible for making sure that your policies and procedures are being followed when it comes to that particular asset. This will ease the burden on whoever is responsible for managing IT by distributing the load accross different teams. It will also give you the assurance that every component in your system is looked after by at least one person. If possible, include this responsibility in each individual contributor's work contract.

A big part of controlling risk comes down to a few simple practices.

But nothing will happen until each practice becomes someone's responsibility.

Schedule small recurring tasks, like reviewing privileged access to critical systems. Have someone look at the logs, and follow-up on anomalies.

Stack up small wins, and build from there.

The more you describe your systems, the more you uncover hidden assumptions.

But that's only the tip of the iceberg.

We expect security people to be all-knowing wizards of technology.

While cybersecurity touches many dimensions of IT systems, the underlying issues relate to the management of risk, trust, and compliance. All of which are organization and business-related, not technical.

When hiring security people, consider that. It's achievable to train someone on the technical dimension of the work. If they are a good cultural fit, they will have better chances of success.

Until you find that number, you won't know how much is enough.

You're making a bet on how much it would be acceptable to lose.

Measure how much it would cost to reduce your risk, then compare the returns with your other priorities. If they're higher, then you found how much you should spend.

1. How much to spend
2. On what

How much should you spend to protect a sandwich?

It depends on how much you can tolerate dry bread.

OK, so what should you use?

There are many options. You could use foil, a sandwich bag, or a plastic container. They have different price points, and different properties. They also involve different operations.

For example, containers are more expensive upfront and you always loose the lids, but you save money over their lifetime. Foil is cheap and in some places recyclable, but if you don't wrap it properly, your sandwich might get exposed.

How much you spend depends on what's at stake. In other words, how much assurance do you need? That's how much you should spend.

What you spend it on is what brings risk to a tolerable level, at the cheapest price.

I bought jonathandupre.com in 2012, but the current iteration started in January 2019.

$ whois jonathandupre.com | grep "Creation Date"
Creation Date: 2012-05-24T02:26:50Z

Blog posts are written in Markdown, with YAML front matter.

I wrote two javascript scripts. A watch script and a build script.

The build script is mostly made up of a bunch of parsers: markdown, pug (html), and stylus (css). It recursively reads templates and content directories. It then builds HTML pages, a CSS file, and RSS/Atom feeds. It also copies over static assets like images and text files.

The watch script is just a wrapper around budo, a Node.js dev server. budo watches the filesystem and calls the build script when something changes.

There are two javascript files.

One is the Fathom Analytics bundle. It counts visitors and views in a way that preserves privacy. I pay US$ 14 a month for this service.

The other one is from ConvertKit and it makes the email list subscription box work. I pay US$ 9 a month for this service.

I use Tachyons as a CSS framework. It helps me have a standard visual style and avoid writing boilerplate classes. I use a cheatsheet to help me find the right class.

The code is hosted on GitHub. I use two branch, the main branch and a development branch.

Netlify hosts the website. They integrate with GitHub. Everytime I merge my changes into the main branch, Netlify runs my build script and deploys the new assets so that they can be served by their web servers.

The DNS records are hosted for free with Namecheap. There's a CNAME at www. that points to the A record, which points to Netlify's load balancers.

The domain name costs me around CA$ 15 a year. That brings the total to about CA$ 30 a month, or CA$ 360 a year.

The website takes under 2 seconds to build. Updates are live under 2 minutes.

And that's about it! I hope this gave you a good example of how you can describe one of your systems.

It might be tempting to include the company's whole IT infrastructure. But chances are you don't have a full-time security team in place, and the quantity of work might end up getting overwhelming.

If you're just getting started, you will benefit from having a smaller scope.

After all, you don't have all the time, money or human resources in the world. And since security is probably not at the core of your business, you'll want to focus your attention on what matters the most.

So how do you reduce scope? How do you make sure you are not wasting your time with unnecessary details? And how do you know you've included and considered every necessary asset?

Start with the obvious

There might be issues that are stressing you out. Or maybe they're stressing out some of your team members.

Write down all of these issues, and consider which assets are affected.

It won't be perfect, but at least you'll start addressing that worry. This will free some of your mental energy and make it available for other issues.

Eliminate unused components

If you have been operating for more than a few months, there might already be components of your systems that are not used anymore. You could add them to your inventory and keep track of them, or just take the steps to get rid of them.

There might be cost savings here, but this is also an opportunity to reduce complexity. If it does not exist, it won't be a source of worry.

Consolidate tools

The average startup uses more web-based software tools than they ever did. I heard recently that the number averaged to somewhere north of 80. Many of these tools have similar features, sometimes the exact same ones.

Look for ways to reduce the number of tools you use by standardizing what tools should be used to solve what problem.

Analyze systems from the inside-out

Imagine a set of concentric circles. The circle at the center represents your "crown jewels". That is, those assets that would put you out of business should they be compromised. Work your way slowly towards the outer circles, noting every system involved in the process. You might be surprised to find that many components of your systems are connected to each other.

Consider your threat model

Who or what are you protecting information from? If this includes adversaries, what are they after? What motivates them? You might find out that you have been putting effort into protecting something that is of no interest to your actual sources of threat, while the assets at risk are left unprotected.

Notice common mistakes

Is there a part of your system that is always responsible for bringing down production? Or that always needs another patch to make it work properly?

Sometimes we forget that availability is also a security property.

Start somewhere

You're better of with a smaller scope at first. This will make the effort more manageable and the small wins will encourage you to keep going. If you're still unsure of what that should be, then just pick a system, and start there.

Ignore the rest until you have some level of confidence that this particular scope has been taken care of.

In short, applying these heuristics will allow you to say, with confidence:

1. We got started.
2. We address our obvious areas of risk.
3. We prioritize our most sensitive assets.
4. We consider the threats that apply to us.
5. We investigate failing systems.
6. We consolidate our tools.
7. We reduce our attack surface.

It leads people to say things like "That's 2 large, 3 mediums, and 4 smalls" and pretend it's meaningful.

I don't recommend t-shirt sizing. But if for some reason it's useful for you, here's a way to fix it.

Take each of your labels, ie:

• Small
• Medium
• Large

For each one, consider two things: the number of people involved, and the number of days it will take them to get the job done.

Use a range to represent your estimates. If unsure, make the range bigger.

With 90% certainty, we can finish a project labeled "small" with 2 to 3 people over 5 to 20 days.

If many of you are making estimates, take a moment to agree on your definition of each label.

Your estimate might still be imprecise, but now you can add numbers and trust the maths will work. Without a clear definition, you can't divide "Medium" with "Small" and expect a meaningful result.

You will be storing their data in the cloud, so they want to know that your security practices meet a recognized standard.

Getting certified means an accountant will visit your firm for a few days. They will ask you to produce evidence that you have different kinds of security controls in place.

The best way to speed up the process of becoming compliant is to avoid processing sensitive information. Look for ways to keep your client's data out of your systems.

You can reduce the scope of the audit by reducing the amount of sensitive information you process.

Before you send out a security questionnaire to a potential vendor, do a rapid risk assessment. This should not take more than 30-60 minutes.

Identify what kind of data the vendor will have access to.

1. It could be secrets like encryption keys.
2. It could be user data, like emails, names and phone numbers.
3. It could be configuration information, like your firewall rules.

Identify how that data will flow between the two organizations.

1. You might be sending them data on a regular interval.
2. You might be creating data inside their solution.
3. Your data might be synchronized between the two systems.
4. They could have direct access to your own internal systems.

Consider what could go wrong if the vendor was compromised, and how bad it would be.

1. What happens if the data is disclosed to the world?
2. What happens if the data is incorrect?
3. What happens if the data is not available, lost, or deleted?

For each scenario, consider the negative consequences.

1. It could impact your company's reputation.
2. It could impact productivity.
3. It could cost money.

Imagine what you could do to mitigate that risk.

1. How can we reduce the access levels that the vendor has to a minimum?
2. What existing controls can we leverage to reduce the remaining risk?

What you should end up with is a list of scenarios (what could go wrong), and a set of solutions for each. You now know what kind of risk you might expose yourself to.

By assuming that your vendor will get breached, you can make the decision to work with them without asking them anything, because you understand your own risk.

Once you've made that determination, what's left is to assess how likely the risk scenarios are to happen.

Ask your vendor the following questions:

1. When was the last time your were breached?
2. Do you have security leadership?
3. Do you have a security program in place?

In the context of your risk analysis, the answers to these questions should determine how many more questions you'll want to ask.

Their breach history will help you understand in what ways they were vulnerable before, and how they respond to events like these. Not having security leadership, or not having a security program in place should be a huge red flag if you want to share sensitive data with them.

Notice that your risk assessment stays relevant even if you decide to not move ahead with a given vendor.

Startups don't have the resources to conduct operations like this. But you might still be able to enjoy the general approach.

The key is in leveraging your existing software development lifecycle.

1. Security subject-matter experts develop threat models with stakeholders.
2. Product managers collaborate with SMEs to come up with attacker stories.
3. During development, software engineers write test generators against those requirements.
4. Site-reliability engineers generate tests and run them against the production environment.
5. Management reviews testing results every sprint.

Incidents caused by tests in production trigger your incident response plan. You can then use these opportunities to train staff, test detection capabilities, calculate response times, and measure the efficacy of plans against expected results.

It won't be as exciting as classic red teaming exercises, but you will be able to go far with a small budget.

It's often a result of doing too many things at once. Scheduling ends up all over the place.

If you standardize the duration of work items, you can use Little's Law to predict your lead time. You can then get a sense of how much work you will be able to ship in a given quarter without having to worry about scheduling.

Throw all the work in a single queue, and limit the amount of work in progress.

You can calculate your lead time by dividing your production capacity by your production throughput.

Lead time = Work in Progress / Throughput

If you can control the amount of work in progress, you can stop managing time.

I'm not the best, but I'm the proof that you can get better.

Here are some of the things I did that helped me get better at interacting with others.

Service jobs: I worked for over a year in a bookstore, a year at a DVD rental, and a summer at a gas station.

Socializing: I participated in 5 applied improvisation workshops and 20 silent disco parties. I played clubs as a DJ in front of crowds of 500 people.

Public speaking: I gave talks at a community center, a public library, a church, and a university.

Hypnosis & coaching: Hypnosis is a lot about communication. I got certified twice. I watched 1,000 hours of training videos. I read 50 books about psychology, sociology, and communication. I helped a handful of people around me.

Writing: I've been writing on my blog and social media since 2012. I write one blog post every weekday since January 2022.

As a teenager, I was too anxious to call for pizza. Now, I feel confident speaking at board meetings.

Sometimes it's good to sit back and remember all the progress you've made. A big part of progression is in noticing it.

The temptation is to celebrate and give the thing back. It feels good to give something back to their rightful owner.

But if they do have the watch, the clerk faces a decision. They need to make sure that that's who you are.

They need to identify you.

The watch has qualities, like color, size, or branding. They found it at a specific place, at a specific time.

If you are who you say you are, you should know about certain things. You hold information that few others hold.

They hold a copy of the same information. But their copy is secret.

To succeed, they need to ask you the right questions. And they have to do it while not revealing their secret information.

You're good at inference. One small detail can give a secret away.

1. What you showed and told them.
2. What you sent them a copy of.
3. What notes they have about you.

Consider the dynamics of each of these sets.

From you, to them, to their organization, to the outside world.

You had conversations, you transferred files. They made evaluations and computations. They took notes and will remember things.

We are custodians of each other's private information.

And information spreads like ink in water.

If you can assure me, maybe I can trust you.

It's to make the insurance provider happy, AND to make sure they are willing to give you money when something bad happens.

If you check the box, but then you don't keep checking it, you risk having to pay the settlement out of pocket.

That gives you two options:

1. Make sure you have enough cash saved up.
2. Understand the requirements of your insurance plan.

If I was hiring a junior cloud security engineering tomorrow, here are 3 high-value projects that I would like to see in the candidate's portfolio.

If you don't understand what any of the vocabulary means, you might not be ready for the job yet. Study, read documentation, run experiments, until you understand every word. Then implement each project in the listed order.

For each project, document your approach to solving it, the lessons you learned while working on it, and what you would do differently next time. Publish a blog post on your website, and the code for what you built on GitHub.

The projects 👇

Secure container cluster

Why? Running apps in containers is how it's done now. But devs don't want to have to think about the underlying platform. How? Deploy a K8S cluster with a reverse proxy, an API backend app, a cache, and a database. Configure the cluster such that only the proxy is exposed to the internet, encrypting all traffic with TLS. Create a set of roles: an auditor that can verify the secure configuration, a sysadmin that can modify the cluster config, and a developer that can redeploy the app.

Secure delivery pipeline

Why? One of the most common needs is to make it possible for developers to ship secure code faster. How? Write a basic app, include 3 different types of bug, create a CI/CD pipeline for it, add code analysis jobs that use industry standard tooling to find the bugs, add a job that outputs a helpful report so that devs can fix it. Bonus points if your solution can also run on dev laptops before they push their code.

Automated response

Why? Tons of changes happen every day in cloud environments and there is no way to keep track of them all. Some of them should never happen in normal circumstances which means you can just automate the response. How? Write 3 detection scripts. Each one should read audit logs, cross-reference information, and then take some kind of action. For example, if an admin signs in from a new IP address, send a Slack message to the team.

By building solutions that are relevant to the teams you will be working with, you will demonstrate that you understand what reality they live in, and that you are competent enough to be trusted with a project.

Computers are great at repetition. But when we run scripts by hand in production:

• We make mistakes.
• We spend unplanned time troubleshooting.
• We stay at work longer to catch up on deadlines.

The amount of wasted effort makes no sense.

You pay so much in lost time and productivity. Sometimes in accrued technical debt. Borrow time from feature development. Invest it upfront in reproducible builds and immutable infrastructure.

You can pay it back in faster deployments, reduced outages, and better estimates.

I heard about this a few months ago, and it didn't surprise me.

I used to think that a measuring tool could only be a physical object. Since then, I learned that an estimate is also a measuring tool.

When planning, agile teams measure the relative size of tasks. This is how they know what features they can ship in the next iteration. I'd be willing to bet that for most teams, these estimates are wrong.

They're so wrong, that I ended up believing that accurate estimates don't exist. But I still went through the motions. It's no surprise they call some of these agile practices "ceremonies".

Guessing is a recipe for disaster. But it feels like that's the only way. You guess "5 hours" and add (an arbitrary) 30%, just to be sure.

Successful software teams measure how effective their measurements are. If you did, you wouldn't be guessing. And you certainly wouldn't use "story points" as a metric.

What I'm about to describe will be familiar to you if you've studied statistics. I wish this would be taught in high school.

If you are measuring time or financial impact, use a range. Two numbers, instead of one. To express uncertainty, describe your confidence level. Or better, agree on a predetermined confidence level for all your estimates. Express that as a percentage.

"With 90% certainty, this will take us between 10 and 20 hours". If you are not that confident in your estimate, expand the range until you are. Assuming that you use 90% as your confidence level, if your estimates are correct, you should be right 90% of the time.

As you get better at this, your estimates become reliable and planning becomes easier. You can take more risks, because you know what to expect. It's like climbing up a ship's mast to see the horizon. You gain visibility into the future.

I'm always a fan of these reports, so I read it for you and wrote this post to give you the big picture.

The context of this report is vulnerability management.

There are two well-known vulnerability databases: MITRE's CVE and NIST's NVD.

There is an average of 50 new vulnerabilities added to these databases every day.

You can't patch every bug.

Remediation is expensive. Sometimes, patching a system will break something, and now a 1-hour project takes you a whole week.

Organizations adopt different strategies to prioritize this kind of work. Some ignore it and hope for the best. Many use the Common Vulnerability Scoring System (CVSS). The goal of this score is to tell you how severe a given bug is.

Even prioritizing using Twitter mentions is more effective than using CVSS.

About 16% of vulnerabilities on the CVE list have exploit code available online. Exploit code is a proof-of-concept script, or a tool, ready to be used to exploit a given bug.

The report labels bugs with known exploit code as "high-risk".

75% of firms have "high-risk" vulnerabilities in over 1/4 of their assets.

Filter the list of all vulnerabilities to include only bugs in systems you are running. Then filter it again to include only those observed in the wild, and only those with known exploit code.

That leaves you with about 4% of published vulnerabilities to worry about.

Exploitability is defined as the probability that a given vulnerability will be exploited in a given time-frame.

If you prioritize "high-risk" vulnerabilities, you can drop exploitability by up to 22x.

This is a good example of how adopting a better strategy can give you better results over spending more.

You can find the full report on Cyentia's website. If you do read it, see if you can find the Star Trek pun.

But a better long-term ROI requires a bigger budget and a longer timeframe. It involves aligning security with your organisation's strategic direction.

That means operating security from the perspective of a business enabler.

And maybe you don't have time for that.

But if you're always firefighting, you won't get better at security by adding another firewall.

This is why you assign ownership. If it's no one's problem, it will never get fixed.

You can bake this in your purchasing process. When approving a new web app, or a new gadget, decide who will be its owner.

This person will be responsible for enforcing information security policies around that system. They will also be the custodian of the information that gets processed and stored on it.

Owners follow security procedures and report about their status on a regular basis.

Assigning ownership allows you to make sure that every issue gets handled. It also makes you think twice before adding more components to your infrastructure.

This is a quick guide on using Kanban for security projects done solo or with small teams.

You might recognize the ideas from the Phoenix Project. The following reflects what I learned from applying them in real life.

Start with a simple Kanban tool

You're gonna need a tool that lets you visualize tasks as cards on a board divide into columns. Most project planning software have some way of representing tasks in this way.

If you are not already using a project management tool, start with Trello. It's a simple to understand web-based software with a free tier.

Divide the board into 5 columns: backlog, next, doing, in review, done.

Dump every todo that comes your way in the backlog column. Schedule a moment at the beginning of each week to plan, and at the end of each week to review.

Make your estimates in units of work session

Scrum planning usually involves story points. More traditional project management uses hours or days. I recommend standardizing the duration of work sessions. 25 to 45 minutes respects human limits. Estimate work by counting how much work sessions you believe something will take.

Chunk and categorize tasks

Every task should fall under one of four buckets:

1. Business projects: Work that benefits the bottom line in some way.
2. Changes: Work that involves operating your existing systems. Toil.
3. Internal projects: Work that involves reducing toil, by automating, integrating, or standardizing.
4. Unplanned work: Work that was not in your backlog at the beginning of the week. This includes incidents.

Add a category as soon as you create the task. Break it down into smaller tasks until you estimate it possible to get it done in one work session.

Pull a fixed number of tasks

Count how many tasks you got done last week. Use that number to determine how many tasks to pull from your backlog.

Tasks with an estimate and a category can move from the backlog to the next column.

Limit the amount of work-in-progress

Insist on doing one thing at a time. Sometimes that won't be possible, so establish a limit on tasks you allow yourself to work on in parallel. Use the scheduled time at the end of your week to re-evaluate the limit you set. Try to keep that number low.

Tasks you are currently working on can go from the next to the doing column.

Don't use a column for blocked items

Make sure blocking tasks stay visible. Whenever you can't make progress on a task, tag it as blocked and leave it there. Since it counts towards you work-in-progress limit, you will be clear on what is slowing you down.

Remember to add management tasks

That time you spent planning ahead? That's also a task. Make sure you add it to your backlog and count it towards your work-in-progress limit. You need to schedule time to improve your workflow.

Measure how right you were

Move complete items to the in review column. Use the moment you schedule at the end of your week to review your estimates. A task was supposed to take one working session but ending up taking 3. A project was meant to take 5 work sessions but you did it in 2. Consider why your estimate was off, take note of it, and leverage that insight in your next estimate. Improve your system week after week.

By applying these ideas, you will find that you adapt better to changes in your environment. You will be able to accept incoming work without stressing out. You will save time planning and getting organized. You will drop the ball less often. You will be able to get clearer estimates of when it will be possible to deliver on any given project. And most of all, you will reduce wasted time and efforts.

I don't have a clear answer to those questions. But I can share an observation that might help you think this through. Or lead you to some insight.

To count without having a concept of a number, you need some sort of a counter. Tally marks, fingers on a hand, shells.

Imagine you're counting sheep using pebbles.

A complete count of every sheep will produce an equal amount of pebbles.

Now, you could re-use the same pebbles twice.

But if you want to store the first number, you will need to store the pebbles. You will have to use a new set of pebbles to count a new number.

If someone is responsible for doing something, then they should have access to the systems they need to accomplish their task.

You can grant permissions based on responsibilities, or you can grant them ad hoc. Granting permissions ad hoc is called an exception.

The more exceptions, the more manual work. Which means more chances for mistakes.

You need exceptions, because your design is never perfect. Edge cases happen every day. But you don't want to hire security staff to handle exceptions all day.

The more you systematize access management, the less you have to spend on access control operations.

If your success rate is 10%, and you want to win 10 times, you have to play 100 times.

That's desired number of wins * number of past attempts / number of past wins.

The inverse of your success rate is the multiplier you have to pay to reach your goal.

You can increase your success rate, or you can play more often.

Improving your success rate gives you the most leverage. But playing more often is always under your control.

The question is, when loss happens, will you be prepared to face it?

We put so much emphasis on prevention that we forget about resilience.

Being prepared means being ready to respond in the face of danger.

Fire drills exemplify this. You rehearse a behavior in a moment of calm so that you know what you have to do when things go wrong. Because when things go wrong, you don't think straight. So you need to practice ahead of time to be ready.

Use tabletop exercises to walk through potential loss scenarios. It's a bit like playing Dungeons & Dragons, but more systematic.

Start with exploring a few likely scenarios, like misconfigurations leading to production downtime. Then cover a few high impact scenarios, like that one risk that is unlikely but could bring your whole company down.

You can keep these workshops short and get good value out of them. Schedule a few sessions throughout the year and invite people from every corner of the business.

You might not prevent every cyber risk, but you will be ready to deal with the unexpected.

All X should Y, otherwise Z.

A rule is a decision.

Trusted agents can write the words, but principals make the rules.

If you focused your remediation efforts on these, you would sort CVSS entries for:

1. Code execution or SQL injection vulnerability
2. Remotely exploitable
3. In a Microsoft product
4. With an exploit available on ExploitDB, Metasploit, or GitHub
5. A CVE that has a higher number of external references
6. Requiring no privileges

Remediate vulnerabilities that are known to be exploited first.

If you start there, you'll get 80% of returns for 20% of the efforts.

Now that it's mostly healed, I appreciate simple things like the ability to bend a knee. Using my leg, really. It made it awkward to put shoes on, for example.

I had the chance to go on a snowboard ride today, but I surprised myself deciding not too. My thought was: "If I get hurt more, then I won't be able to go for even longer."

This is interesting, I think, because it's probably a common thought.

The point is, it's not that I want to protect my knee, it's that I want to make sure I maximize having fun. That's my metric. Will I still get to have fun?

You don't have to be an expert in security to get that. In fact, maybe working in security makes us forget that sometimes. "It's for your own good". Remember hearing that as a kid?

So I'm not going snowboarding today. To protect the fun.

You can reduce the number of evaluations by asking the following 3 questions:

1. What kind of data will they process?

Don't waste time investigating vendors you don't need to trust with sensitive information.

2. What's our standard for protecting this kind of data?

For a given data sensitivity level, they shouldn't do worse than you. It's okay if they do as good, it's great if they do better.

3. Do we have any reasons to believe they might not hold the same standard as us?

If your standard for security is high, chances are you had to prove that to your clients before. How did you do it? Match the level of assurance that you give.

You might not have all the information today. But you can always re-evaluate your decision in the future. Documenting your decision will help you do that, and it will demonstrate that you have considered your options wisely.

Last week, they published a bulletin to remind the cybersecurity community to raise awareness about Russian-backed cyber threat activity.

They shared a set of recommended proactive network monitoring and mitigations for Canadians organizations.

Be ready to isolate components

1. Consider which components of your system would be attractive to disrupt.
2. Be prepared to isolate components and services, both from the internet and from internal networks.

Increase organizational vigilance

1. Spearphishing campaigns get increasingly sophisticated. Equip yourself to detect and manage their impact.
2. Monitor your networks with a focus on the TTPs reported in the CISA advisory.
3. Make sure IT teams focus their cybersecurity efforts on identifying and quickly assessing unexpected or unusual network behavior.

Enhance your security posture

1. Patch your systems, with a focus on the vulnerabilities in the CISA advisory
2. Enable logging and backups.
3. Deploy network and endpoint monitoring.
4. Implement multifactor authentication where appropriate.
5. Create and test offline backups.

Have a cyber incident response plan

1. Plan for the continuity of operations.
2. Plan for emergency communications.

Inform the Cyber Centre of suspicious or malicious cyber activity

You can report information to the Cyber Centre to help them provide advice, guidance, and services.

They will ask you when the event happened, when you made the discovery, what was affected, what was the impact, and if the situation is under control.

You will then categorize the event under 1 of 7 categories.

Actions:

• Denial of service - Attacks that prevent the use of networks, systems, or applications by exhausting resources or making services unavailable.
• Social engineering - Tricking people into misbehaving or divulging secrets, using knowledge of human behaviour.
• Improper usage - Conduct that violates IT security or other policies, or that impacts the c/i/a of computing resources.

Results:

• Unauthorized access - Someone accessing a system or information without authorization
• Identified vulnerability - Flaws that could be exploited by attackers.
• Information breach - Disclosure of sensitive data outside of its security classification or need-to-know.
• Malicious code - Code meant to disrupt the c/i/a of one or more computing resources

Remember that the CCCS might share information you put in these forms with their public and private partners. This includes details like URLs, IP addresses, device details, and email addresses.

One way to add value in security projects is by removing noise. Sometimes you have enough information, but you also have too much of it to sift through.

Bad information can sometimes be worse than no information at all.

Look for ways that you can delete a draft you never finished, archive documentation that is out of date, or retire a whole app no one is using anymore.

Burn the old wood before it rots.

The weights should get heavier as you progress. It would be impractical to buy infinite weights, so you buy them in fixed weight increments.

You use a range for your number of reps because you have a discrete number of weights. Ranges have a lower and an upper bound. They are useful because they give you room for manoeuvre.

In a perfect world, you would address risk in real-time. But you work as teams and organize work in projects. And deadlines mean pressure.

So your number of reps should reflect your goals. You should expect less reps per set if you are working with heavier weights.

Having trouble reaching the lower bound is a sign that your goals are too ambitious.

Reaching the upper bound with ease for too long is a sign of stagnation.

But when you get close to the upper bound after honest effort, it's a sign you are ready for the next level.

What it looks like influences how you prepare.

1. Likely and high impact: Fix this now. Deploy changes and hunt down threats.
2. Likely and low impact: Focus on prevention. Manage risks, inventory assets, and model threats. You want to be systematic.
3. Unlikely and high impact: Focus on recovery. Have a contingency plan, build redundant systems, and train people. You want to be ready.
4. Unlikely and low impact: Follow best practices. Stay vigilant. Remember that small things add up.

You control likelihood by making sure it doesn't happen. And you control impact by being ready to adapt.

It provides a schema for core identity resources (such as users and groups) and a set of REST operations.

The API is implemented by many Identity Providers (like Okta) and it lets you provision users automatically on apps like GitHub, AWS SSO, and Jira.

The goal of your program is to train people on a continuous basis without interrupting them in their work.

You can integrate basic training into the onboarding process, and provide advanced training on an ongoing basis.

Include in your basic training:

1. Understanding your acceptable use policy.
2. Creating and storing passwords.
3. Evaluating the sensitivity of information.
4. Sending secret messages using a secure channel.
5. Reporting security incidents.

You want to train people on topics that are relevant to the objectives of the organization but also to their own success at their job. Topics for advanced training should be decided at the beginning of each quarter and the content selection adapted for the needs of different groups.

At this point in time, or as a first I recommend:

• For executives and directors: Getting the most out of tabletop exercises.
• For people managers: How to communicate during a crisis.
• For developers & system administrators: How to coordinate effectively during outages.

Update job descriptions to reflect the responsibilities that people have.

This is important because you want the training to match people's level of access, and you can't verify people's level of access without accurate job descriptions.

You can ask IT to provide you with a spreadsheet that lists out everyone’s permissions to make this task easier.

Host a Q&A session about cyber security every quarter. People who participate should be eligible for prizes.

Measure progress by using standard engagement metrics. Ask your favorite marketing friend to help you with that.

Make your initiative educational but engaging.

Help people feel like they are part of something bigger than themselves, and that their participation matters.

A basic security posture gives you benchmarked assurance.

An advanced security posture gives you controlled assurance.

A mature security posture gives you the right assurance.

You can now duplicate a secret at the speed of a social network.

Having read access means being allowed to ask questions about a set of numbers.

You can ask a computer for the contents of a file, or your eyes for the color of the sky. If someone has read access to a file, assume they will copy it and distribute it to their peers.

Computers, like people, are networked by default.

The engineer told me that the only option was to lift the house, destroy the old foundation, and build a whole new one. A project that would cost well over a hundred thousand dollars.

Every other option, to him, is hacky and unsafe.

He's not wrong. His plan is the only kind of project he can deliver with a full guarantee. His arguments were sound. His explanations honest. But something didn't feel right.

This is interesting, because it has nothing to do with his ability to deliver. In fact, his firm has a stellar reputation for doing quality work.

But as much as I could appreciate his advice, I couldn't bring myself to trust it. I knew he had something to gain. His business card even says "specialist in house lifting".

There is this intuitive sense that you can't rely on a biased statement. It sounds so obvious, too.

And yet, in most software shops, the IT department is responsible for IT security.

That's not an issue when you're getting started, because everybody trusts each other. You know you can believe your sysadmin when they tell you there is nothing weird in the logs. You trust that evaluation, because of who they are. You trust them.

But as you grow, roles change and tasks get delegated. You hire, and soon, the organization is three times the size. The sysadmin is now a small IT department. And the fox is guarding the hen house.

Growing is messy. And we have to trust each other if we are to work together. Administrative controls get burdensome, so keep it simple.

1. Divide critical functions among different members of your team.
2. Ensure no one has enough access privilege to cause damage on their own.
3. Review job responsibilities and work contracts on a regular basis.

When the engineer tells you, "Let's do this right", you won't have to think twice.

The reason why they had to take them down is simple: the work involved in identifying the impacted systems is simply too much for the resources available.

That decision was a wise one. They compared the potential loss associated with keeping the sites up with the cost of taking them down and determined that it would be less expensive to take them down.

It would have been very difficult to guess that this specific event would happen. This case doesn't even involve an actual loss event or an adversary. It would have been difficult to reduce the probability of this kind of event.

In this particular case, society at large is paying (eg. lawyers can't do their job without having access to some documents that are only available through government systems). Every day that these systems are down probably involves millions of dollars in wasted time, without even counting the cost of actually solving the issue.

However, had they had an up to date inventory of their system, the cost of mitigation could have been substantially lowered. With a proper inventory, they could have answered the question: "How many of our systems are affected?" and only taken down those. We would have collectively saved millions of dollars. And yes, keeping an asset inventory is not free either. We make tradeoffs when we decide which security project to work on.

This is one project though that always pays off in the end. How can you know you are deploying the right quantity of resources if you don't even know what you are protecting?

You have an easy to find "security" page on your website. It gives me an overview of what safeguards you put in place, what principles your follow, and the assurances that you can give me.

Security features are included by default in your free plan. I don't want to have to pay more money to unlock granular permissions, single sign-on, or encrypted communications.

You are transparent about your architecture. Bonus points if you can show me system diagrams. Your system should be secure even if your enemy knows how it works. There is no good reason to hide how data flows through your solution.

You don't ask for more permissions than you need. If your integration asks me for things I know it doesn't need, you're asking me to choose between safety and productivity. Either I accept to expose data, or I stop what I'm doing to handle the risk. The principle of least privilege also applies to permissions you request.

You publish content that helps your clients protect their information when using your software. No solution is perfect. When you educate your clients on how to use your product safely, you tell me that you probably considered how it could be misused.

You made it easy for me to back up my data. I don't have to jump through hoops to make sure I have more than 1 copy of anything important. I can export to standard file formats without thinking too hard about it.

The strongest signals show me that you have given this some thought. Find ways to demonstrate that you won't ruin my day.

A simple process you can use

A simple way to approach this challenge is to enable the end-user as much as possible.

1. Publish a document management policy that describes the different security levels a document can be labeled with and a scheme for document version control.
2. Create templates for each document type so that team members don't have to add more effort to their existing workload.
3. Progressively label old documents as you update them.
4. Assign ownership of directories where those documents reside to team managers. They will now be responsible for enforcing the document management policy inside that directory.
5. Add a clause that reflects this new responsibility to employment contracts for each of these roles. Make sure that both the manager and the person they report to sign this new change.

Documents should be classified and versioned

Security levels can be:

1. Secret (Red) - Consulted on a need to know basis. Access controlled. Encrypted in transit and at rest. Kept in a secrets data store.
2. Confidential (Orange) - Consulted on a need to know basis. Access controlled. Encrypted in transit and at rest.
3. Internal (Yellow) - Shared internally only. Access controlled if shared externally. Encrypted in transit.
4. Public (Green) - Sharing is encouraged.

Efforts should be made to move documents from orange to green as early as possible in an effort to reduce the volume of data to protect.

For versioning, you can use a simple scheme with two numbers, major and minor. Start with 0.1, incrementing the minor number every fix and incrementing the major number when something important changes.

Remember to add cover pages to documents. This is where you will be adding the most obvious and visible security labels. Modern apps like to show you a screenshot of documents and without a cover page you might expose sensitive information.

One of the first thing I noticed is that over 30% of the 100+ hacks did not involve smart contract security. That means that about a third of the attacks could not have been prevented with a smart contract audit.

I see many crypto startups describe their security practices in terms of the number of smart contract audits they have received. Many protocols also have a bug bounty program on Immunefi or similar platforms. It goes without saying that these are necessary practices. It's not just data we are protecting, but funds. Smart contract risk is serious, and scary.

But there are other common loss scenarios:

• private keys are stolen
• backend systems misconfigurations are abused
• intruders compromise bridging servers
• malicious insiders collude

The decentralized finance industry built a $2 trillion financial market without institutional help. The possibilities boggle the mind. But we build these new protocols on top of the same distributed systems used by the legacy industry.

Many of the security challenges you will face live at the boundary between distributed ledgers and public clouds.

I can feel incompetent and sad that others are better than me.

Or I can feel a sense of wonder and joy at how other people use their creative ability to create something wonderful.

I passed the exam in 2021. I was asked recently about my experience getting the certification and this is what this post is about.

First, keep in mind that if you want your certification, you will need an endorsement from someone who is already certified. So start thinking about that early so you don't waste time after you passed the exam.

I asked someone in my network who trusted me for an introduction. I met with that new connection and we got to know each other. He verified my experience and made sure that what I was saying was true. Eventually he accepted to endorse me.

I booked my exam date a month ahead. By that point I had been studying for a few months. I heard people recommend you book your exam date before you start studying, giving yourself 3-9 months depending on your level of experience. I agree with them. The point is, it's easy to push it back to later out of fear, and never doing it. So just commit to a date, and get to work.

I read many Reddit posts to get a sense of how people were studying, and what I was up against. Some answers were coming back again and again, so I focused on these resources.

I bought these following books:

• (ISC)2 CISSP Official Study Guide, Sybex - Each chapter has a quiz at the end. So I started with going through the quizzes. For each question, I would write down my best answer, and draw a little flag if it was just a guess. Then, I'd go through the chapter, and focus on understanding the content related to all the answers I flagged. This allowed me to put more attention on topics that I was less familiar with.
• The Official (ISC)2 CISSP CBK Reference - I think I barely opened it. But it was great to have when one of the topics in the official study guide were not covered in enough details.
• (ISC)2 CISSP CISSP Official Practice Tests - I went through all the practice test questions in this one the same way I did with the official study guide.
• 11th Hour CISSP - It helped me get a sense of what was the most important to know for the exam. I bought this one towards the end.

I also used two apps to help me go through a volume of practice questions:

• I did a few of the practice exams in the Boson ExSim-Max app. The questions had a different style than the Sybex books, which helped me get a different perspective on each topic.
• The best bang for my buck was the IT & Security Pocket Prep mobile app. It did between 10 and 30 questions a day, again, flagging the questions I was just guessing. By the end I was scoring 90% and over most of the time.

The last resource I would recommend is Kelly Handerhan's 16 minute video titled "Why you WILL pass the CISSP". I watched it a few times before taking the exam. It's an excellent recap of the mindset you are expected to adopt.

The exam was challenging, but I got excellent results.

So the TLDR: Book your exam early. Do a few practice questions, flag questions for which you wouldn't be able to give an explanation for your answer, study the topics behind the questions you flag. Repeat.

PS: Remember to study the ISC2 Code of Ethics

I hope this helps!

• Simplify the architecture. Lower cognitive overhead means less bugs.
• Build tools around the development process. Optimize for developer workflows.
• Write specifications. You probably won't do it before you start shipping code but it's never too late.
• Monitor running systems. You want to be able to know what state your system is in, from development to production.

Improve your system security so that you're able to trust your systems more as time goes on.

You can't depend on an external company to own this work for you.

Build capacity instead of dependency. It's core to your business to understand your product and to be able to manage it.

Look for ways to simplify your existing system first.

Modern IT infrastructures change quickly, and assumptions don't age well.

Where do you think your beloved app is the weakest?

Try to break it.

Keep track of the steps you took to test things and see if you can automate them. Then run those on every deploy.

You will be wrong one day. Make sure you find out early.

It made us way more productive. This guy has been working on it for a while, now. He used this new web app that lets you connect two APIs together without writing code.

But he left a month ago. And he didn't really document it.

No one knows how the integration works. We just don't touch it.

But yeah, it's business critical. If it fails, it will probably take operations down until we fix it. Who knows how long that could take.

It probably won't fail, though.

Right?

Your infrastructure engineering team might already be working on finding these cost savings. After all, they do have experience trying to turn things off to see if anyone is still using it.

But they also have to keep production up, help developers, and deliver projects. This doesn't leave much time for trying to cut waste. So you need ways to free up DevOps time.

Investing in projects that involve making developers self-sufficient often helps. These often involve improving processes and writing lightweight automation. Examples include local development environments, accessible application logs, and reproducible builds.

Reducing the amount of unplanned work makes a big difference. Engineers lose valuable time switching contexts, and frequent firefighting saps morale. You control unplanned work by reducing the number of tasks running in parallel, using automated tests, and keeping your systems simple.

You can free up resources by reducing unplanned work and investing in projects that make developers happy.

This will not only give you some of your margin back, but also reduce your attack surface, and increase your team's understanding of how your systems work.

When you question stories you've been telling yourself, you unleash uncertainty. Accurate insights can be unpleasant.

Who wants to pull on the thread that seems to be holding the sweater together?

To really see, you need to be away from the urgent, the day to day. You need to give yourself perspective. And when you step back and look at things on a larger scale, you don't always like what you see.

But not looking is worse. Because you know this will get worse later. Dead tech rots. Then it grows into a monster.

So you address problems as they arise, you sort them out as you go.

You refuse to pay the price of inaction.

The opportunity involves creating some new system.

Your PM has a quick meeting with the developers, and they determine it will take them 2 weeks max. You decide to put existing projects aside, and try to deliver the strategic project fast.

The lack of planning shows up in the failure to ship on time.

Then something breaks production. Everyone is upset. After wasting a week on fixing the problem, you lose the opportunity.

This is a common story of how technology risk becomes business risk.

The good news is that you can ship fast and avoid issues like this.

But first let's look at some of the hidden costs of creating a new custom system.

1. The cost of maintenance. Your new system will be full of bugs. These will cause outages and take time away from development.
2. The cost of short-term thinking. You will forget to consider how this system will evolve. New features will be needed, but your initial design might not allow for that. The estimated cost of adding that feature now needs a multiplier.
3. The cost of missed learning opportunities. You did a lot of things manually in the beginning. Then you automated them. You will be tempted to automate tasks that you haven't performed manually before. You will lose on the opportunity to capture these important lessons.
4. The cost of operations. Automation involves operations. Who is going to operate your new system? That might involve running scripts, checking alerts, or just verifying that the thing still works. Does your team have time for that?
5. The cost of problems piling up. New systems are rarely built in isolation. You can expect them to integrate with existing services. Those interactions will have side-effects on production. These problems will take forever for your team to solve, because they will be invisible.
6. The cost of complexity. Learning how this system works and operates with other components adds cognitive load to everyone involved. This means they might make more mistakes, which will create more problems.

New systems need planning, integration, operations, maintenance, and documentation. The real cost of a custom system is more chaos.

Your team has the competence to identify all of these issues, and more. They probably already did. But they won't tell you.

Help your team develop habits needed to raise potential issues before they cause damage.

Encourage speaking up about potential issues, pushing back, and challenging the status quo.

Make it easy for your organization to learn from its mistakes.

Here are some of the questions I had for the product team. These might be relevant to your product, or they might help you consider things from your customer's perspective.

Notice how my primary concern might not be clear from the questions I'm asking.

Someone else entrusted me with their data. If something were to happen, I want to be able to tell them that I made a responsible choice when I signed up for this web app.

You have team members responsible for answering customer requests. If needed, could they access my account to help me troubleshoot a problem?

If that is the case, what permissions does an employee need to access my account? What information will they be able to see? How long will they still have access to it? How do you know that permissions have been revoked? How many employees currently have this level of access to my account?

Sometimes you will need to investigate security incidents. Do you log authorization requests? How much detail do you include in your logs. How long do you keep logs around? How often do you look at them? How do you make sure that no one tampered with the logs?

I'm not the only one with an account on this platform. Is my data isolated from other users? If someone accessed my account due to a bug or human error, how much data would they be able to access? Would you notice an incident like this? How long would it take for you to respond?

Sometimes things go wrong. Are you keeping backups of all my files? How do you make sure that those backups work? How many people have access to these backups? Are the controls used to protect data in the application the same as those used to protect backups?

I might need to exit your platform at some point. Can I export my data if needed? How complicated is it? Does it include everything?

I admit that it's kind of annoying to have to answer questions like these.

Until you get security under control, you'll spend hours struggling so you can close your deal. In the meantime, these questions can help you think things through some more. It's easier (and cheaper!) to design with security in mind than to tack it on at the end.

1. Knowing where my data is
2. Controlling access to it
3. Monitoring anomalies
4. Taking action if something goes wrong
5. Making sure that the monitoring works properly

To be successful, you need to figure out how to do this on a continuous basis, and to get better at it over time.

If you need a security assessment, you can get very different types of engagements depending on who you speak to.

You use threat modeling to determine what kind of dangers you are exposed to in your line of business. You wouldn't add a bunker to your basement without having a serious reason to believe you might need.

You use a vulnerability assessment to determine what areas of weakness exist in your operations. They cost a lot of money and they create more work for you. They can be automated.

You use a risk assessment to paint a picture of how things might go wrong. How often and how much will you lose? These assessments are inexpensive, and you should do them often. But you need some understand of your threats and vulnerability.

A threat is a danger, a vulnerability is a weakness, and a risk is a potential loss event.

Don't get confused by the techno-babble. If you understand this distinction, you will understand what you are buying.

Blockades closed the Ambassador Bridge for for about a week. The financial losses were estimated between 300 and CA$ 400 million each day.

To help put a stop to the funding of these blockades and other illegal activities, the Government of Canada declared a public order emergency.

If your truck is being used in these protests, your corporate accounts will be frozen. The insurance on your vehicle will be suspended. —The Honourable Chrystia Freeland, Minister of Finance

The act invoked extends the scope of Canada's anti-money laundering (AML) and counter financing of terrorism (CFT) rules. It covers all forms of transactions, including digital assets such as cryptocurrencies.

Following my curiosity led me to wonder about the underlying regulatory framework.

It's called the Proceeds of Crime (Money Laundering) and Terrorist Financing Act. Or PCMLTFA.

The Act has 5 regulations.

It comes down to:

1. How to register a Money Services Business.
2. How to report suspicious transactions.
3. How to report of big cross-border transactions.
4. Compliance requirements. Things like KYC, record keeping, and what kind of transactions to report.
5. Penalties for not being compliant.

FINTRAC has a privacy policy. One of the annexes describes the provisions that the PCMLTFA contains to promote the privacy of Canadians.

• Unauthorized disclosure is punishable by up to 5 years in jail, or a fine of up to $500,000 or both.
• FINTRAC's Annual Report includes the management guidelines and policies for the protection of human rights and freedoms.
• FINTRAC must report why it needs access to information.
• Records are kept for 10 years.
• Records that are no longer under suspicion can be destroyed.
• There's a long audit trail.
• The Office of the Auditor General audits FINTRAC's operations.

I don't know how I feel about the powers that can wield financial intelligence agencies.

But with a bit of research I notice that care went into making sure that the information collected is used responsibly.

The question remains: what is the impact of using this kind of control, in this kind of context?

You can block change requests until they get approved. Or you can let changes through and catch any error in operations. If your strategy requires you to go fast, you might need to do the latter.

It's like taking a loan. You don't have the time capital right now because you're still getting your business off the ground. You accept to pay some interest in accumulated risk.

It could be very risky.

But doing business is risky. And there might be morale cost to slowing down development with long debates.

If a change request introduces changes you disagree with, you can still approve it. Approve it under the condition that an objection gets logged.

The important part is reviewing them.

Have a way to make sure that objections get reviewed. Sometimes you will need to revert changes. Sometimes you will have a good reasons to create a new policy. But often you'll realize that it was no big deal.

Your data can be disclosed, corrupted, or denied of access.

Let's say you want to close 10 deals over the next quarter. To achieve that goal, you will use computers to access all kinds of data. It might be customer information, financials, or contracts. It might be historical records, a list of some sort, or maybe a piece of code.

If your mission depends on it, add it to the scope.

1. How probable it is that an event will occur
2. How bad you would have to pay if it did

This gives you two levers for risk control: likelihood, and impact.

You can reduce the likelihood of an event occurring. And you can reduce the impact of that event, if it were to occur.

They are both important parts of a good security program.

The first lever is "Prevent".

Sometimes, you can bring likelihood all the way to zero. For example, you can choose to not store sensitive user information. This is the decision to avoid risk.

Or you can reduce the likelihood by an order of magnitude. You can give a third-party responsibility for protecting a given data set. This is transferring risk.

In both cases, you are trying to prevent something bad from happening.

The second lever is "Prepare".

When you put in place a control to help you detect or recover from an issue, you are controlling the impact.

For example, you could use a service to watch the status of your website, and alert you if it goes down. This won't prevent the website to go down, but it will reduce the downtime.

A solid backup program eliminates most of the impact of ransomware.

In any case, discussions about control selection should be nuanced. Remember to consider different view points when listing pros and cons.

The unique perspectives that your team members will contribute might surprise you.

The more data, the more private data. The more private data, the more liability.

So there's an inherent risk to better apps.

• Sometimes you'll be ready to handle it.
• Sometimes you have to accept it, because that's the way it is.
• Sometimes that's unacceptable, you don't have the resources to handle it.
• Sometimes you can plan ahead and invest in an action plan.

We want better apps, which means we should expect some level of risk.

You must:

1. Protect it against any anticipated dangers to its security or integrity.
2. Protect it against any anticipated uses or disclosures that are not permitted or required.

That means you need to:

1. Identify what kind of PHI you process
2. Consider how it moves inside and outside your company
3. Consider what threatens its security (the dangers you anticipate)
4. Evaluate your current security safeguards
5. Assess the likelihood of a breach of your safeguards
6. Put a plan in place to reduce the likelihood until it's low
7. Make a reasonable amount of effort to implement the plan

When evaluating vendors, ask them to tell you how they assess and control risk. Never do business with a vendor who's standard is lower than what your clients expect from you.

If you follow this process, audits will be easy, and you won't spend more money than necessary.

A risk is an uncertain future event with meaningful consequences.

You describe security risks through scenarios that might happen in the future:

"During <a time period>, <a threat> abuses <a set of vulnerabilities> in the <security controls> protecting <a set of systems>, reducing the likelihood of reaching a <business goal> by <a ratio>".

Vulnerability is only one part of the story.

Until you provide every component of the risk scenario, you won't know if the impact is meaningful.

1. Adjust <time periods> to the event horizon you are looking at.
2. Conduct inventory management and architecture reviews to get a list of your <systems> and <security controls>.
3. Do vulnerability assessments, configuration reviews, and penetration tests to identify <vulnerabilities>.
4. Perform threat modeling and gather threat intelligence to identify <threats>.

Use forecasting to estimate the impact on the bottom-line, and focus on protecting business goals.

Measuring risk will help you prioritize potential remediations with the other important things that your budget can buy.

You usually partner with a third-party that handles some of the details for you. They list your program on their website and you receive reports by email.

The main benefit is obvious.

You will get a large number of reviews, and only have to pay when a bug was found.

The downsides are less obvious.

It will take time away from your development team, which will slow you down. Most of the reported issues will be already known. After all, you don't have enough time to fix the bugs you already know you have. You won't have a big enough scope. You won't be reacting to reports fast enough. The rewards you will want to pay out will be too low. A waste of time for both you and researchers.

In short, you are not ready to have a bug bounty program.

There are two things you can do until you are:

1. Work on your fundamentals.
2. Launch a vulnerability disclosure program.

It's a policy that protects security researchers when they disclose vulnerabilities to you.

You can draft one in an afternoon.

It should include a safe harbor clause, a scope, clear guidelines for submitting bugs, and rules of engagement.

Make it easy to find by publishing it in your security.txt file. Include a public PGP key so it's easier to communicate with you in private.

If you do get submissions, you can still reward researchers. If they're a customer, send them swag, too. And if they aren't anonymous, recognize their achievement in public.

Make sure to record the researcher's contact information. You can invite them to your (private) bug bounty program when you do have one.

You won't have hackers working full-time to report vulnerabilities to you. But honest users will feel safe communicating the bugs they do find. And you'll have saved both time and money.

The protection of ownership comes with another secret to protect.

At the end of the day, you have to accept some kind of compromise between security and usability. You can make that decision explicit by measuring the risk. But you still made that decision when you decided to not store that key in another vault.

You don't even know how many. Who's keeping count?

You have a lot of data.

Look at your cloud drives, your download folder, your browser history, your access logs. There are treasures in there.

You pay to store data you will never use. Then you hire a vendor to sell you someone else's data.

You have the ability to herd fleets of compute nodes and wrangle data streams across networks.

You don't need more stuff.

Infrastructure engineers have a good sense of where spending could be improved, and they understand how they could benefit from having a smaller attack surface.

If you don't have a budget for cloud security, consider examining how much you spend on infrastructure. You might be surprised by what you find.