The term “secure by default” has been thrown around a long time for various kinds of products and services. Google claims “secure by default” from the start, Apple claims privacy by default, and Microsoft lists secure by default as optional, but recommended in most cases.
What does “secure by default” mean anyways? In some instances it can mean having back-up security protocols in place to automatically revert to e.g., if you have an electronically powered on a door, also having a you have a physical lock so un the event of a power outage, the door will revert to a secure locked state, versus having an open state. This allows for a hardened configuration that mitigates a certain type of attack. In other cases, it means defaulting to a more secure pathway. For example, many internet browsers force traffic to move over https when available. By default, many users are presented with a lock icon and a connection that initiates over port 443, or https. Now over 90% of the internet traffic flows over this much more secure protocol and users are alerted if their traffic is not encrypted. This also mitigates manipulation of data transfer or snooping of traffic. There are a lot of different cases and the term has inflated over the years.
Now what does this mean for the average company as you implement security systems and protocols? I am often faced with implementing rollouts of security and privacy initiatives. Each of these initiatives vary in time and cost, but at the core they are often necessary because a software application or software integration lacks a particular security configuration that is needed to protect the company, and is thus not “secure by default”. There are a variety of reasons that this happens:
- Infrastructure updates: New equipment or systems are brought in line that change the architectures and footprint of the company. These are often big changes, such as multi-region availability, new data centers, or new product lines that introduce new attack surface area.
- Configuration updates: New technology is deployed that changes how systems are configured and maintained. This could be ranging from infrastructure as code deployments using terraform, or migrating to Kubernetes architecture.
- Scope updates: The application has changed in scope since it was deployed. This could be the result of increased users, increased usage, or deployment to new environments. Scope changes are common as integrations for data access increase, especially for analytics or artificial intelligence.
- Feature updates: New features have been added as part of the software development lifecycle and changes must be deployed to adopt these features. These features often get enabled for new tenants, but if you are a legacy tenant, you will often need to deploy settings manually.
While each one of these points comes with its own set of changes, I want to focus on the last point as it relates to third party cloud vendors, specifically around two critical functions: email and identity. My advice is to look at the concept of secure by default, not as a static building principle, but as a continuous control that needs to be reviewed over time.
Every program starts as “secure by default for now” or at a given point in time. We are long removed from the days of static software; releases come frequently and often without user interaction. Take a SaaS platform like Gmail for example. Many of the current security features have come over the course of the last 10 years, and many of them are not enabled by default. The same goes with identity providers like Entra ID (formerly Active Directory), Ping or Okta. It’s critically important to review these platforms at least monthly and evaluate new security features for your organization.
