Forem: Sturdy

Stop Using Acronyms

Sturdy — Wed, 27 Jul 2022 16:29:00 +0000

I recently was invited to a vendor lunch and learn. Here is the subject -

OCP Platform - ACS and ACM - ODF Advanced

I didn't go. I don't know what all of the acronyms mean.

That example came from a vendor, but we do this to ourselves all the time. Here are a few email/meeting subjects I've had in my inbox recently

SI-2 & RA-5 Escalation Step 1

Implementing MTLS for SSO for our app

OD4B and SPO

Unless you work with those terms on a regular basis, you aren't likely to know what those mean.

Why Do We Use Acronyms?

We tend to use acronyms for a couple of reasons, but I think it really comes down to speed. It is just faster to write SPO than it is SharePoint Online. But there is a less obvious reason we use acronyms - it makes us feel good. In the book The Upside of Irrationality, Dan Ariely talks about how acronyms can be used to communicate about ideas in shorthand. Those not familiar with the ideas don't understand the acronyms. When you know what the acronym means, it creates this sense of cohesiveness of being part of the "in" crowd.

The downside to using acronyms like this is that it keeps outsiders out. It becomes difficult to break into the "in" crowd. For those of us that have been at a company for many years, some of the common acronyms aren't new to us, but when you try talking to new employees, across departments, or sometimes even teams, those acronyms don't always translate.

Not only can the acronyms not translate, they are often overloaded. If I'm working with our web services team and I'm talking about SSO, it stands for "Single Sign On". If I'm working with a security team and talking about SSO, it stands for "System Security Officer" (or at least I think it does - a SSO is definitely a Security Officer of some kind).

Acronyms Are Exclusive Language

When we use acronyms, we are using an exclusive language where only people in the "in" crowd will know what we are talking about. Others are left to ask questions or use Google to figure it out. Using the Google method, I figured out what the meeting request I mentioned above was about - the Oregon Catholic Press's (OCP) Platform with the American Chemical Society (ACS) and the Association for Computing Machinery (ACM) for the Oregon Department of Forestry's (ODF) Advanced [force]. That would have been a long title, I'm glad they used acronyms. While that might have been interesting, I'm glad I didn't go.

All joking aside, I really don't know what the meeting was about. I may have been needed. It may have been about something that impacts my work. I don't know and I made the decision to not attend in lieu of other, more well-defined work.

As part of my job, I teach new, entry-level employees on various programming techniques and technologies we use. Over the years, I've learned there are a lot of different acronyms we use and just expect people to know. If you are curious about how often we slip into acronym world, try teaching. It will highlight where we expect people to understand acronyms.

Not All Acronyms are Bad

I do believe we should cut way back on using acronyms, but there are certain acronyms that aren't all bad. There are acronyms that are part of every day life that we can continue to use - USA, NYC, SCUBA, DMV, GEICO, NASA. There are acronyms used specific in technology - IT, SDLC, API, HTML, XML. Everyone knows what those mean. Go ahead and use those shortcuts. On the other hand, if there is any doubt about whether someone will know what you are talking about - do not use the acronym.

If you are on the receiving end of an acronym you don't know, make sure you speak up and ask about it. If you don't know, there are likely plenty of other people who also don't know.

TL;DR (Too Long; Didn't Read)

Stop using acronyms if they aren't widely known.

Secure Software Design

Sturdy — Wed, 22 Jun 2022 01:35:07 +0000

As part of the Executive Order on Improving the Nation's Cybersecurity, there is a provision in Section 4, subsection s that says

The Secretary of Commerce acting through the Director of NIST, in coordination with representatives of other agencies as the Director of NIST deems appropriate, shall initiate pilot programs informed by existing consumer product labeling programs to educate the public on the security capabilities of Internet-of-Things (IoT) devices and software development practices, and shall consider ways to incentivize manufacturers and developers to participate in these programs.

When I first read this, I got excited. I think that as a whole, we in the development community don't naturally build in security to our applications because we've never been taught what that means. This is an opportunity to improve that.

I've looked into it and I haven't seen too much published, but I knew The Linux Foundation played some major roles in various parts of the Executive Order, so I started to explore what they had available. And I found it - training about secure software development through the Open Source Security Foundation (OpenSSF).

https://openssf.org/training/courses/

As it should, the training starts off with how to design secure software. Here are a few of the high-level points you can take away without actually taking the training

Requirements

Security should be an integral part of the requirements of any software application. Specifically you should think about the following:

Confidentiality

Which information should not be publicly revealed? Who is allowed to see the data? Can we avoid having that information at all? What about passwords - how are they stored?
Integrity

Which information should only certain people be allowed to modify? Who are those certain people?
Availability

This is a hard one as availability is rarely an absolute. How can we develop our software so it isn't easy to overwhelm? Can we build our applications to scale up with load? To protect against corruption, make sure the data is backed up to cold storage.
Non-repudiation

Is there an action that we want to prove someone took?
Identity & Authorization

How do people prove who they are? We should implement two factor authentication whenever possible.
Authorization

Who is allowed to do what? Implement role based security.
Auditing/Logging

What events are important to record? Login, logout, user creation, user deletion are a must. The format for the record should include when it happened, what happened, what system component did it, and who caused it to happen.

Privacy

Privacy is the right to be left alone, or freedom from interference or intrusion. Information privacy is the right to have some control over how your personal information is collected and used. Various countries and cultures have wildly differing views on what a person's rights are with regard to privacy.

When setting privacy requirements, often the best thing to do is to not collect information. When you don't collect information, you don't have to tell people how you use it, you don't have to figure out a strategy for the misuse of the information. If you need to collect personal information, you must provide protections for them.

The European Union has a comprehensive privacy regulation - General Data Protection Regulation (GDPR). The Linux Foundation has a summary worth reviewing for additional information.

Managing Risk

If people start using the software you develop, expect that intelligent adversaries will try to attack it. Don't wait to address risk. If you ignore risk until something happens then they are now problems. Addressing risk now is easier and cheaper than addressing problems later. Additionally, it is better for professional and organizational reputations to address risk before they are problems.

Identifying risk is something a lot of people are not very good at. Most of us try to use things the way they were meant to be used. As an example, when you go vote, have you ever tried to vote twice? That is the mindset we need to start addressing risk and the best way to get there is to start doing it now and continuously improve. Software we designed 5 years ago with security in mind is likely not secure anymore.

Security is rarely once and done

Someone once told me, "we have to be right 100% of the time, but attackers only have to be right once." I don't know anyone that is right 100% of the time, and NIST agrees with me. They've put together Cybersecurity Framework that should be followed when an incident occurs. Here are the high-level steps:

Identify

Develop an organizational understanding to manage cybersecurity risk to systems, people, assets, data, and capabilities
Protect

Develop and implement appropriate safeguards to ensure delivery of critical services
Detect

Develop and implement appropriate activities to identify the occurrence of a cybersecurity event
Respond

Develop and implement appropriate activities to take action regarding a detected cybersecurity incident
Recover

Develop and implement appropriate activities to maintain plans for resilience and to restore any capabilities or services that were impaired due to a cybersecurity incident

Secure Design Principles

These are just rules of thumb for building in security, but they should never replace thinking and doing the right thing. These are the same secure design principles put together in 1975 in The Protection of Information in Computer Systems.

Least Privilege

Each user and program should operate using the fewest privileges possible. This principle limits the damage from an accident, error, or attack. It also reduces the number of potential interactions among privileged programs, so unintentional, unwanted, or improper uses of privilege are less likely to occur.
Complete Mediation

Also known as non-bypassability. Every access attempt must be checked; position the mechanism so it cannot be subverted.
Economy of Mechanism

Ironically also known as simplicity. The system, in particular the part that security depends on, should be as simple and small as possible. Easier to review, harder to get wrong.
Open Design

The protection mechanism must not depend on attacker ignorance. Instead, you should act as if the mechanism is publicly known, and instead depend on the secrecy of relatively few and easily changeable items like passwords or private keys. An attacker should not be able to break into a system just because the attacker known how it works. Security through obscurity generally doesn't work.
Fail-safe Defaults

The default installation should be the secure installation. if it is not certain that something should be allowed, don't allow it.
Separation of Privilege

Access to objects should depend on more than one condition (such as having a password). That way, if an attacker manages to break one condition (e.g., by stealing a key), the system remains secure.
Least Common Mechanism

Minimize the amount and use of shared mechanisms. Avoid sharing files, directories, operating system kernel execution, or computers with something you do not trust, because attackers might exploit them.
Psychological Acceptability

Also known as easy to use. The human interface must be designed for ease of use, so users will routinely and automatically use the protection mechanisms correctly.

Reusing Software

Looking at the composition of applications, a very large majority of the code is reused. It could be proprietary or third-party, open source software. When we reuse software, regardless of the source, we need to consider a few things.

Is the software easy to use securely? If it isn't easy, then it likely won't be used securely.
Can evidence be found that the authors of the software are working to make it more secure?
Is the software maintained at all?
Are there other people using the software?
What license is applied to the software? A lack of a license is a big red flag - a lot of countries make it illegal to use unlicensed software.

And even with all of those questions answered, don't be afraid to do your own review. Run a static analysis tool against it, check for TODO statements, are there tests?

If you are using Open Source Software, you should never fork it to make changes. Contribute the updates back to the community. Forking makes receiving updates very difficult. If Google had a hard time with it, I can't imagine you will do better.

And lastly, if you are using software from a third-party, you should try to keep it up to date as much as possible. The further out of date you are, the harder it will be to upgrade.

Conclusion

That was a long, but brief introduction to the training available through the OpenSSF. If this is of any interest to you, I highly recommend going through the available training material they offer.

https://openssf.org/training/courses/

Hello, I'm Sturdy and I'm Burned Out

Sturdy — Tue, 24 May 2022 17:58:40 +0000

I read a blog post about burnout and I've been thinking about that post a lot recently. I'm finding it difficult to remain motivated and even with taking some time off, I'm not feeling refreshed when I get back. I have a hard time not feeling like all I'm doing is hitting my head against the same very hard wall over and over.

In parallel with my normal work, I'm also going through a leadership training program at work where we are taking classes to help us learn about ourselves, how others perceive us, and how we can strive to improve our leadership abilities. For anyone who knows me, I am one of the biggest introverts you've ever met. I don't like to be around a bunch of people, especially people I don't know very well. Going through these classes, especially because they are in-person, is a source of anxiety for me.

I have a problem. I think I'm burned out and have high anxiety, which isn't helping the burnout.

Reflection

How did I get here? I'm honestly not sure. As that original blog post points out, burnout is a little like slowly boiling to death. It is difficult to point out one thing that got me here. It is likely lots of little things that add up. I've been saving up my vacation, so I haven't taken a lot of time off from work. Some of the things I've been working on, I've been working on for 3+ years and we've made only minimal progress. I've enjoyed working from home, but I'm now coming into the office more than I used to - and I did mention I'm an introvert, right?

What Am I Doing About It?

Well, I started off with a list of things that give me energy, and these are the things that I'm going to focus on for a bit. Here is my list, depending on your personality, yours will likely look different.

Learn a new language - while I've been dabbling in learning some Spanish, I'm talking about a different kind of language. I'm trying to learn Go. With more talk about microservices, I've always heard that Go is a good language to quickly build them.
Spend time outside - as part of the leadership training classes, I took a Birkman assessment and I have interests solidly in the outdoor group of activities. I've started going to the park more with the dog, getting out on the motorcycle more, and doing more yard work.
Find more focus time - Microsoft Teams has been great for keeping up to date on what is going on. I have notifications set to Always for a large number of channels. I've never felt more connected to the work going on. Unfortunately, this also means constant interruptions. I wish Microsoft Teams had features like we have in Slack. I want to have pre-scheduled 'Do Not Disturb' windows where I see no notifications except those which I am specifically mentioned in. For now, I am manually turning on/off 'Do Not Disturb' during certain hours of the day to focus on work.
Taking more breaks - yes, I'm saving up my vacation, but that doesn't mean I can't take breaks. Periodically throughout the day, I am stepping away from the computer and going outside with the dog and playing in the yard. Or maybe the dog and I will hop in the truck and go for a drive. My goal with these breaks is to not look at a screen. No TV, no phone, just disconnect.

National Alliance on Mental Illness

Burnout is a form of a mental health issue and mental health issues in tech are rampant. If you didn't know, May is Mental Health Awareness month. And for me, the more we talk about it, the more it feels "normal." There shouldn't be any stigma associated with mental issues and as a tech community we need to support each other. The National Alliance on Mental Illness (NAMI) is a group that offers free mental health resources including education, support and advocacy.

I hope that if you are having issues then reading this helps you realize you aren't alone and may give you some ideas on things you can do to help in your life. If you need help and blog posts like this aren't enough, I recommend checking out NAMI at https://www.nami.org/. There is a lot of educational material on their site and you can find local affiliates that can have additional resources like weekly support group meetings.

Zero Trust Explained

Sturdy — Wed, 13 Apr 2022 11:17:29 +0000

Last year, the President signed an Executive Order to improve our Nation's Cybersecurity, and part of that Executive Order was a direction to use Zero Trust Architectures to access cloud assets. I have talked to a few people over the last couple months about the impacts of the Executive Order and one of the reoccurring themes is that there isn't a clear understanding of what Zero Trust is. So let's hit some of the high-level points here so we can all be on the same page. And if I've missed something in this list - please let me know.

Origin and Concepts

The term was originally part of a whitepaper called No More Chewy Centers: Introducing The Zero Trust Model of Information Security which was released by Forrester in 2010. The paper lays out that our traditional networking model is like an M&M - hard and crunchy on the outside and soft and chewy on the inside. Meaning it is hard to get into the network, but once you are in, it is pretty easy to move around. The author points out numerous cases where this has been a problem. One of those stories is about Philip Cummings, who used to work at the help desk at TeleData Communications, Inc (TCI). TCI provided software to credit bureaus like Equifax, TransUnion, and Experian. Through his job duties, Philip had access to all of the passwords and API keys to access all three of the major credit bureaus. While he was working at TCI, a Nigerian crime organization told Philip that they would give him $60 per credit report he was able to send to them. Philip left TCI in 2000, but before he left, he saved off the password and API keys for the credit bureaus in order to send credit reports to the crime organization. It is estimated that he sent over 30,000 credit reports in the next two years until the theft was noticed in 2002.

The Philip Cummings story shows us it is hard to trust people inside our networks, but people have an identity. When we move to the network level, the packets sent across the network have no definitive identity. We can tell where they are coming from, where they want to go, and what the request is. There is no identity. Trusting that packets are legitimate is something we all do, but in computing terms, what does that mean? Because there is no concept of identity, how can we trust packets? We can't. We shouldn't.

Zero trust means that we should never have the soft chewy center. All networks should be treated as untrusted. This will ensure security is baked into the network. In order to implement this, Forrester lays out these concepts:

Ensure that all resources are accessed securely regardless of location - treat all traffic as if it were coming from the internet, even internally.
Adopt a least privilege strategy and strictly enforce access control - use something like role based access control to control what people have access to.
Inspect and log all traffic - most companies log traffic data, but very few inspect it

Forrester makes the point that monitoring the security of 100's to 1,000's of applications is difficult and can be done in as many different ways as there are applications. Fortunately, access to these applications is all done the same way - through the network. Implementing security at the network level is easier and more effective.

Lastly, the paper lays out that cloud traffic isn't going away and we need to have a better way to verify and monitor that traffic. Implementing Zero Trust never ends, much like Agile, Zero Trust is a way of thinking, not a prescriptive method for implementing security. "Trust, but verify" can no longer be our standard, instead it should be "Verify and never trust."

Themes throughout the paper highlight the benefits of using Zero Trust -

More secure against insider threats
More secure against external threats when using a "defense in-depth" strategy
Ultimately cheaper to maintain than the traditional "defense in-depth" options

Standards - NIST 800-207

Since the whitepaper by Forrester in 2010, the evolution of Zero Trust hasn't stopped. In 2020, the National Institute for Standards and Technology (NIST) released publication 800-207 - Zero Trust Architecture. As it is with any Government publication, it is a dry read and is full of acronyms, so here is my summary of the document.

The seven tenets of a zero trust architecture:

All data sources and computing services are considered resources. Big or small, simple or complex, all systems on a network are considered resources. This should also include Software as a Service (SaaS).
All communication is secured regardless of network location. There is no trust, there is only untrust. All devices, regardless of network placement should be treated as untrusted devices.
Access to individual enterprise resources is granted on a per-session basis. Trust in the requester is evaluated before access is granted and may include time-based rules. Granting access to one resource does not automatically grant access to another.
Access to resources is determined by dynamic policy - including observable state of client activity, application/service, and the requesting asset - and may include other behavioral and environmental attributes. Trust should be contextually based. Meaning taking into account the patterns of the user, including time of day, device being used, versions of operating systems, among others.
The enterprise monitors and measures the security posture of all owned and associated assets. Enterprises should be able to answer the questions: what is on the network, who is on the network, what is happening on the network, and how is data protected on the network. Associated assets are any other assets allowed to connect to enterprise resources; this likely includes personally owned devices.
All resource authentication and authorization are dynamic and strictly enforced before access is allowed. Zero Trust Architectures have a continuous cycle of obtaining access, scanning and assessing threats, adapting, and reevaluating trust.
The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture. Enterprises need to continually collect data about security postures, network traffic, and access requests and use the data to adjust policies.

There are a bunch of different models for a zero trust architecture. Most of them look similar to this picture:

While there are a lot of acronyms there, here is the core concept - any person or service account (subject) uses a system to access Enterprise Resources. A policy enforcement point is added somewhere in the middle of it to intercept the request and send it through policy engine to make a decision on whether access will be granted. The policy administrator takes inputs from various sources to help guide the creation and evolution of policies used by the policy engine. There are different ways for the policy engine to make a decision. One of the more popular methods is a scoring system where the contextual data is weighted in a certain way and if the cumulative score of the request is over a threshold then the access will be granted. If the cumulative score does not reach the threshold then the subject is presented with a challenge of some kind to allow them to raise their score.

I think things are always easier with an example, so let's see what it looks like if you are trying to connect to a GitHub Enterprise instance.

As you make the request to the GitHub Enterprise instance, your traffic is intercepted by the policy enforcement point. Here is some of the data that comes along with your request:

IP Address
Geolocation
Time
Date
An identity

The policy enforcement point sends this traffic to the policy engine which see that the traffic is coming from a place within the United States, it is an IP address that has accessed the system before, by an identity that is valid. The time might be a little off though. Maybe this request is being made at 1AM on a weekend - hours when you don't normally work. Those two last data points would lower the score and this request might not meet the configured threshold. Instead of allowing you access to the GitHub instance, you are instead redirected to a challenge page to allow you to prove you are who you say you are. Maybe you will need to re-enter your RSA PIN and token, or maybe you will have to respond with a code sent via text message. Once complete, the policy engine will raise your score and allow you through to GitHub Enterprise. This flow would happen whether you are physically within the enterprise network, working from home, or travelling anywhere in the world.

How to Deploy Zero Trust Architectures

The short answer - it will be a journey. NIST 800-207 does provide some guidance on how to migrate to a Zero Trust Architecture depending on your current network configuration. One of the big pieces to consider is the policy engine and the administration of the scoring. It is likely that with the initial implementations there will be some issues where traffic is denied when it should have been allowed. We will have to make sure we set expectations as we work through this process.

Based on the NIST documentation, there might be some good first steps for us to start implementing Zero Trust.

Identify Actors in the Enterprise - these are humans as well as service accounts
Identify Assets Owned by the Enterprise - includes physical, virtual and data assets (like user accounts)
Identify Key Processes and Evaluate Risks Associated with Executing Process - find a system that is relatively low risk to the business; cloud-based resources are a typical first step
Formulating Policies for the Zero Trust Architecture Candidate - find all supporting systems for your candidate and start setting the initial thresholds for score
Identify Candidate Solutions - we need to pick a solution that matches our existing asset policies and tooling
Initial Deployment and Monitoring - the initial deployment might limit traffic to only coming from specific locations and might be in report-only mode to allow us to gauge how well our scoring system works
Expanding the Zero Trust Architecture - with the confidence built in the previous step, expand the criteria for accessing resources and add more resources to add

Conclusion

Unfortunately, this isn't something we can do with the snap of a finger. This will take time to implement and gain confidence in. One of the hardest things to prove out here will be return on investment. Will we ever be the victim of an insider threat? What will the cost of a breach be? Is it worth spending money to try to prevent something that we don't know will happen?

I think it is.

We might take a different perspective on return on investment though. If we look at this like insurance, we are paying for a possibility of a breach in smaller increments now. The determination of return on investment will depend on typical actuarial items, likelihood of the event and the potential cost of an event.

References:

Zeroing in on Zero Trust Podcast - https://open.spotify.com/episode/28o5axMB5tjSUzms03bmyk?go=1&sp_cid=90f1110ab844846f3afe849e3c5e5621&t=3&utm_source=embed_player_p&utm_medium=desktop&nd=1
Zero Trust Security Explained: Principles of the Zero Trust Model - https://www.crowdstrike.com/cybersecurity-101/zero-trust-security/
NIST 800-207 - https://csrc.nist.gov/publications/detail/sp/800-207/final
No More Chewy Centers: Introducing The Zero Trust Model Of Information Security - https://media.paloaltonetworks.com/documents/Forrester-No-More-Chewy-Centers.pdf