Asking the right questions in Cloud Security
Nothing in life is to be feared; it is only to be understood. Now is the time to understand more, so that we fear less.
Marie Curie
2025 SANS Cloud Security Exchange was the most incredible learning experience. Those new to the industry simply have to be a part of of attending SANS events such as this.
I recently attended SANS 2025 Cloud Security Exchange, where I learned more about designing end-to-end security architectures using Zero Trust principles. The opportunity to learn directly from some of the most influential leaders in this domain was unparalleled; SANS publicised this as being the event of the year to directly interact with the guest speakers, providing an opportunity to learn what may take years, if one expects such nuggets of knowledge to come from experience. The speakers were generous with their time and thoughtful in their responses--making the take aways more than knowledge to apply as best practices, this became an experience where any one can ask questions. Whether you are an experienced professional seeking answers to questions, or if you are new to the industry and excited to learn and interact with such knowledgeable veterans of the industry.
One of the most notable interactions was with Wesley Kuzma, Senior Director of Securitt Architecture at Microsoft, who shared valuable insights drawn from his experiences building strategic workflows. I hope to apply his knowledge to monolithic, legacy environments operating in highly regulated industries. His feedback helped to further refine my body of knowledge regarding AWS's Well-Architected Framework and molding it to companies which have to deal with compliance and governmental regulations. Such a matrix I have yet to come across, yet I think the first step to effectively apply this information is to imagine a matrix with an inverse relationship, using cost-optimisation and the attack surface as variables for the x/y axis. This matrix is then able to be further refined, resulting in a custom dashboard which is able to be constructed into a visually aesthetic "Quick Glance" summary for executive decision-making.
The most effective network architecture begins with the end in mind.
Wesley emphasised the importance of starting with the end in mind, sculpting frameworks to support the goal and only then, identify the services and actions which support that goal. For example, consider the objective of understanding the cause of latency for a SaaS application running on a cloud-based application server. What factors directly impact that latency? Some of possible solutions come from experience--knowing what to troubleshoot instinctively based upon previous use cases. Other solutions come from having applied best practices, with the intent to reduce technical debt, and minimise occurrence of the same general issue. Wesley's advice helped me to be more conscientious and remain focused on the outcome of an end goal for a given use case, when seeking a solution with this perspective. Any monitoring, maintenance, or configuration services which do not help to answer the key question should be omitted.
Easy to discern, a lifetime to master.
Of course, eliminating seemingly unnecessary services is not so simple. Anyone who has worked with on-premise, monolithic architectures knows that some components function in unexpected ways, often outside of best practices. These may become distractions--the "what if this service might help" moments; to manage this, the workflow should be transferred to a flowchart, filtering options until the most optimal answer emerges. There is rarely one perfect solution. The flowchart provides one the ability to visually determine a "best" decision for the given use case.
If organisations must over-collect logs, what services are able to refine the workflow, making it as cost-effective as possible while adhering to applicable frameworks or models.
Querying logs is not about collecting every possible service or log--from the technical side. Instead, it is about asking the right questions and structuring solutions around clear end goals.
The burden of over-collecting logs due to regulatory and compliance requirements is an unavoidable responsibility. Yet, attempting to decide which services to use, and to what extent, is dependent upon variables, one of the most critical variables is how to optimise the services in a cost-effective manner--the incorporation of such tools as Amazon OpenSearch, a data lake (whether cloud-native or partner service), and LifeCycle Management policies, as well as storage services must be balanced with regulatory/compliance policies. From this step, the next decision should support how the integration of these services may yield the results which allow for executives to make the most optimal decisions for the company.
Whether troubleshooting latency, managing technical debt, or handling compliance-driven log collection, the key lies in disciplined focus--filtering out distractions and creating a framework which delivers answers executives are able to validate and rely upon.
In conclusion, these lessons open the door for new questions: How does one refine these frameworks? How to maintain the balance between compliance, cost, and security to yield a framework which has been time-tested and validated--making it sustainable. These are the challenges which keep the field of Computer Network Security both demanding and endlessly fascinating.
Comments
Post a Comment