Good Security Is Holistic

It’s important to understand that security is an emergent property of your overall product or system health — it’s not an isolated feature that gets shipped and is then relegated to minor upkeep. Rather, similar to your own personal health, security requires ongoing maintenance and consistently applied proactive care.

Good Security is built into Your Process

Building a secure system is a lot like living a healthy lifestyle. It’s an ongoing process of conscious decisions, which means your security process must be deeply integrated over the lifecycle of your system. To accomplish this, your security team needs to be collaborative peers to the engineering and operational teams — ideally embedded as active contributors to the development and maintenance of your systems.

• Design process — Organically evolved systems are among the most expensive and painful to secure — assuming it’s even possible. So, you need a clear design process where security can provide feedback, propose alternative approaches, and identify (and ideally prevent) the potential for security issues in later stages.
• User Experience — Security UX is often relegated to an afterthought — if it’s thought about at all. However, a good security UX is essential to ensuring users make responsible trust decisions and avoid dangerous risks. Broadly, this involves avoiding unnecessary decisions by providing secure defaults, and ensuring clear information is provided at the correct time and in the context of a necessary trust decision.
• Development practices — Inconsistent process is a very strong signal of both poor security and poor code quality, because it usually means the development team lacks broader understanding, communication, and clear ownership of their code. Even small things like inconsistent style and formatting policy can obscure subtle bugs and dangerous patterns. (Apple’s “goto fail” bug is a great example of how consistently enforced coding style would have prevented a particularly bad vulnerability.)
• Change/code reviews — Any project of significant scope needs clear ownership of individual components, and proper review of all changes/check-ins (beyond the simple mechanical stuff). Security should just tie into this process directly, reviewing any changes to security sensitive components, or providing security expertise where appropriate.
• Dependencies — It’s critical to maintain a solid understanding of the security impact of any libraries or systems that you depend on. That means understanding any attack surface or TCB increase that such a dependency might introduce, along with the overall security quality of dependencies. And be especially considerate when adding dependencies, because they put you on the hook for tracking their security updates and deploying them as necessary.
• Testing — Any changes to the codebase need proper test coverage (unit, system, and integration, as appropriate) ideally run as part of a continuous integration process. For TCB components, this simply guarantees that things are working as intended (e.g. “goto fail” should have been prevented by tests). However, the larger value is that robust tests provide freedom to make significant changes, because they’re the only way to be confident that you haven’t broken anything when, say, a security fix requires a major refactor. And of course, security-focused fuzz-testing is essential whenever handling things like file format parsing in memory-unsafe languages.
• Deployment — If you cannot reliably and safely deliver up-to-date software, then you cannot provide a secure product or maintain a secure system. That’s because security is always a moving target, requiring that updates be delivered in response to discovered vulnerabilities or for necessary security improvements. Simply put, an out-of-date system — or worse, a system that cannot be reliably updated — is a fundamentally unsafe system. (Duo Labs’ recent work covers a range of real-world failures here, particularly on the “safely deliver” front.)
• Telemetry and metrics — Data from the field is extremely helpful in informing security decisions. It can be used to: assess the effectiveness of security UX, identify low-usage features for removal, expose potentially exploitable crashes not yet exercised by tests, or even detect abuses and compromises in the wild. Unfortunately, most security investment today is in that last point (detection in the wild), which is arguably the least effective thing to do at this stage.
• Bug triage — Security vulnerability reports are just a specific kind of bug report, but they generally warrant a faster turnaround and confidential handling. So, your bug triage process needs to account for this by assessing the impact of vulnerabilities and prioritizing as appropriate. If you’re confident in the maturity of your process, you may want to further incentivize security reports via a bounty program.

Deprecations — Sometimes security issues can be fixed only by breaking compatibility for some existing use cases. So, it’s essential you have a clear policy and timelines for deprecations. This includes establishing criteria for when short deprecation timelines are required to address severe security issues, versus longer timelines for general security enhancements and improvements.

Good security is early and simple

Security is far more cost effective if you start early and incorporate it into the lifecycle of your system. Prefer simple, proven, integrated solutions over complex, trendy, bolt-on technologies.

Good security is forward looking

Reliable updates are the basic foundation of any security effort.

Good security is audited

However, random screening is better than systematic one : “You could perhaps feel better by setting up employee checkpoints at entry points, but you’d hassle a lot of people at great cost with minimal additional benefit, and a smart, patient terrorist could find a way to beat you. a random, unpredictable screenings that can and do occur everywhere, all the time (including delivery vehicles, etc.) are harder to defeat. With the latter, you make it impossible to engineer an attack; with the former, you give the blueprint for exactly that.”

Security is a state of mind, not a state of being.

https://medium.com/@justin.schuh/stop-buying-bad-security-prescriptions-f18e4f61ba9e