Security Stack Sheet #107

 

Word of the Week

Can We Have “Detection as Code”?

One more idea that has been bugging me for years is an idea of “detection as code.” Why is it bugging me and why should anybody else care?

First, is “detection as code” just a glamorous term for what you did when you loaded your Snort rules in cvs in, say, 1999? Well, not exactly.

What I mean by “detection as code” is a more systematic, flexible and comprehensive approach to threat detection that is somewhat inspired by software development (hence the “as code” tag). Just as infrastructure as code (IaC) is not merely about treating your little shell scripts as real software, but about machine-readable definition files and descriptive models for infrastructure.

Why do we need this concept? This is a good question! Historically, from the days of first IDS (1987) to the sad days of “IDS is dead” (2003) and then to today, detection got a bit of a bad reputation. We can debate this, to be sure, but most would probably agree that threat detection never “grew up” to be a systematic discipline, with productive automation and predictable (and predictably good!) results. In fact, some would say that “Your detections aren’t working.” And this is after ~35 years of trying …

Links HERE and HERE and HERE and tools HERE and commercial HERE and (expensive) course HERE

 

Word of the Week Special

“Security Architecture Review Of A Cloud Native Environment”

Due to its massive adoption, cloud computing has become a critical component for every enterprise. A large number of organisations want to migrate to the cloud, however, its security posture is still a blind spot for everyone. Nevertheless, we have seen a big rise in the number of requests to check the security posture of cloud infrastructure deployments.

In this blog post Anand Tiwari will talk about a cloud security assessment that he did for an organisation, which had recently moved their infrastructure from an on-prem to a cloud native solution (AWS). Assessment was carried out in two parts, an architecture review was done and a security gap analysis was performed. The blog will detail how the assessment was conducted and why a cloud security assessment is needed, in addition to a standard application/infrastructure pen-test

Link HERE and Exploring cloud trust relationships in AWS HERE

 

Bonus

a close up of text on a white background

Link HERE

Diagram  Description automatically generated

Link HERE

Image

AND

A picture containing text  Description automatically generated

Link HERE

A screenshot of a cell phone  Description automatically generated

Link HERE

 

Crypto challenge of the week

A picture containing text  Description automatically generated

Link HERE

 

Dates

  • May 25th 2018: Over 2 years of GDPR Live! See incidents section below GDPR Enforce Tracker Link HERE – thanks to Marius

a close up of text and logo on a white background

Link HERE

  • 1st January 2020 – The California Consumer Privacy Act (CCPA) becomes effective Link HERE
  • Now: TLS1.2 mandatory for proper security HTTPS everywhere HERE
  • DO NOT DELAY TLS1.2 migration LATER THAN JUNE 2020 or A FEW THINGS WILL STOP WORKING! [Browsers, Office365, Cisco and many others]
  • January 2020 – Qualys SSLLabs will rate your TLS1.0 setup as B – Qualys will de-grade you HERE
  • June 2020 – Microsoft plans to deprecate TLS versions 1.0 and 1.1 in Office 365 and Office 365 GCC – HERE
  • 31st of December 2020 – Brexit (properly) Finalised?
  • 1st of July 20201 – Freedom from viruses?
  • November 3rd 2020: Trump’s second term start

Text  Description automatically generated

Link HERE

  • 2022 – First trip to Mars according to Elon Musk
  • 2023 – 3DES is deprecated for all new applications and usage is disallowed after 2023 HERE
  • 2024 – Back to the Moon according to Trump and NASA
  • December 31st, 2020 Flash End-of-Life
  • US Government Websites Will be Accessible Through HTTPS Only, After September 1

 

Book of the month

Designing APIs with Swagger and OpenAPI

A great introduction to the design process of APIs by helping you to understand OpenAPI and Swagger

Link HERE

Program analysis

Software is transforming the way that we live and work. We communicate with friends via social media on smartphones, and use websites to buy what we need and to learn about anything in the world. At work, software helps us organize our businesses, reach customers, and distinguish ourselves from competitors. Unfortunately, it is still challenging to produce high-quality software, and much of the software we do use has bugs and security vulnerabilities. Recent examples of problems caused by buggy software include uncontrollable acceleration in Toyota cars, personal information stolen from Facebook by Cambridge Analytica, and a glitch in Nest smart thermostats left many homes without heat. Just looking at one category of defect, software race conditions, we observe problems ranging from power outages affecting millions of people in the US Northeast in 2003 to deadly radiation overdoses from the Therac-25 radiation therapy machine. Program analysis is all about analysing software code to learn about its properties. Program analyses can find bugs or security vulnerabilities like the ones mentioned above. It can also be used to synthesize test cases for software, and even to automatically patch software. For example, Facebook uses the Getafix tool to automatically produce patches for bugs found by other analysis tools. Finally, program analysis is used in compiler optimizations in order to make programs run faster

Link HERE

 

Comic of the week

Karma Is Real - Dilbert by Scott Adams

 

##Some OWASP stuff first











Leave a Reply

Your email address will not be published. Required fields are marked *