Hello again world, this time in Wix format. For those who do not know us yet, we are Semper Victus, a cabal of consultants and organizations bringing forward their capabilities and assets to create "awesome things" and break "not so awesome things" in the hopes of making them better. For the first post on our commercial blog, lets start it off with some background and thoughts on design - a function we perform in tandem with implementation or as wholly separate endeavors.
For a bit of context: our teams have operated in financial services, healthcare, and other security sensitive organizations for our bread and butter for the better part of the last decade building blue-team technologies, infrastructure, and finding ways into things which were intended to prevent our ingress. We form teams per-engagement to deliver the proper talent and tooling where and when it's needed, we train together and with peers from our clients' teams, and we take pride in building things which experts say could never work. The world in our eyes consists of client deliverables, and while we are a technology company, what we do is create value in the business logic of our clients' operations and their client-facing systems.
The majority of our work focuses on blue-team objectives around securing SoA's and point targets, collecting and analyzing threat and behavioral telemetry by the terabucket, and responding to hostile action (real or perceived) against our clients. The functions supporting these objectives can be implemented at any or all segments of the technology lifecycle - design, implementation, and maintenance. All too often we find ourselves on the ground in the last phase, tasked with plugging all the holes of a sinking sponge, or in the middle where we are asked to prepare a glass yacht for combat operations. With the aid of proper talent and technology, both of those approaches are feasible, but still far from ideal because they inherently contradict design elements which either did not take security posture into consideration, or explicitly eschewed it for performance or functionality/ease.
With that in mind, the point of this post: Defense in Depth can only be achieved by incorporating security considerations from the design phase onward, as tactical action does not constitute strategic posture. For example, financial, healthcare, and some state regulations require formal plans of action to address breach conditions. These clauses effectively have no context in implementation other than to provide functions supporting a plan, and organizations retroactively implementing measures to support plans which have not been written nor distributed to stakeholders for acceptance should switch from burning dollars to some form of cost-efficient fuel. In compliance-beholden environments, the implementation of security controls/functions will occur one way or another, and if initial design did not account for them, it will get trampled by an army of attorneys in the best case scenario.
A technical example of this condition would be scoping a proprietary hypervisor or storage system with black-box semantics into a project requiring full audit trail from TPM-attested boot to user-level service access, including the actions of adversaries who manage to get execution on/access to the system. If the audit requirement comes up after everything is built, then massive efforts have to be taken to replace the hypervisor while migrating its VMs, storage, networking, etc. A far more common example in commercial implementations is the ubiquitous "Big Data Fiasco" - developers figure out that they can meet numerous business objectives by collating and crunching multiple sources of data, show charts to management, get approval and build it, only to find out in the end that:
The regulations governing the elements of data they wish to "mix in" prevent such collation.
The stack does not meet the legal requirements for working with/storing production data.
The result sets produced lack the provenance necessary for them to be used for production activity.
So if you're looking to reach out to a consultancy like ours or to ask your in-house IT provider to build/extend something, bring your objectives and your security requirements to the table at the onset. Performance quotients can be determined based on the projected impacts of security requirements from the beginning, same with resiliency, components, and the resulting resource requirements in time and materials. The testing methodology for deliverables can be written from day one to verify the efficacy of control and audit functions along with operational objectives, and maybe most importantly, schedules and budgets will not be skewed by a blocking security failure discovered just before (or after) go-live. To my knowledge, no one has ever been fired for proper prior planning.