Book Review: Clean Architecture

This is the review of the Clean Architecture (A Craftsman’s Guide to Software Structure and Design) book.

(My) Conclusion

I personally have mixed feelings about this book; the first 4 parts of the book that presents the paradigms and different design principles are quite good (for me it contains all the theory that you need in order to tackle the IT architectural problems). You start reading from the first chapter and gradually you build knowledge on top of previous chapter/s.

On the other side, the part 5 and 6 of the book (which are representing the backbone of the book) have a different cognitive structure; the chapters are not really linked together, you cannot read and build on top of previous chapter/s because there is no coherency between chapters (some of the chapters are extended versions of blog tickets from https://8thlight.com/blog/).

The book explains very well the rules and patterns to apply in order to build an application easy to extend and test but the subjects like the scalability, availability and security that are qualities that an (every) application should have, are not treated at all.

Part I Introduction

The author tries to express the fact that good software design and (good) software architecture are intimately linked and that is very important to invest time and resources in having a good software design even if it looks like the project it advances slower.

The quality of the (software) design will influence the overall quality of the software product and to prove this the author comes with some figures/numbers (unfortunately there are reference to the source of this figures).

Part II Starting with the bricks: Programming Paradigms

The following programming paradigms are explained: Structured ProgrammingObject Oriented Programming and Functional Programming.

For each paradigm a brief history is done and also the author expresses how each paradigm characteristics can help and impact the software architecture.

  • the immutability characteristic of Functional Programming can help to simplify the design in respect of concurrency issues.
  • the polymorhism characteristic of Object Oriented Programming  can help the design to not care about the implementation details of the used components.
  • the Structured Programming helped us to decompose a (big) problem in smaller problems that can be then handled independently.

Part III Design Principles

This part is about the SOLID design principles; each one of these design principles are clearly explained using sometimes UML diagrams. The solid design principles are (usually) applied by software developers to write clean(er) code but  the author also explains how these principles can be applied to an architecture level:

  • SRP (Single Responsabilty Principle)  for a software developer is “A class should have only one reason to change.” but for an architect became “A module should be responsible to one, and only one author”.
  • OCP (Open-Closed principle) is translated in architectural terms by replacing the classes with high level components the goal being to arrange those components into a hierarchy that protects higher-level components from changes in lower-level components.
  • LSP (Liskov Substitution Principle) is translated in architectural terms by extending the interface concept from a programming language structure to gateways that different system components are using to communicate. The violation of substitutability of these gateways (interfaces) are causing the system architecture to be poluted.
  • ISP (Interface Segregation Principle) is translated in architectural terms by stating that generally is harmful that your systems depends on frameworks that has more features that you need.
  • DIP (Dependency Inversion Principle) is used to create architectural boundaries between different system components.

Part IV Component Principles

The components principles are categorized in two types: (component) cohesion and coupling.

The component cohesion principles are :

  • (REP) The Reuse/Release Equivalence Principle : This principle states that “The unit of reuse is the unit of release”. Classes and modules that are formed into a component must belong to a cohesive group and should be released together.
  • (CCP) The Common Closure Principle: This principle is actually the Single Responsibility Principle for components. The principle states that should gather into same component classes that changes for the same reason at the same time.
  • (CRP) The Common Reuse Principle: This principle states that “should not depend on things that you don’t need it”. This principle rather tell which classes should not be put together in the same module; classes that are not tightly bound to each other should not be in the sane component.

This principles are linked together and applying them could be contradictory. The following diagram express this contradiction; each edge express the cost hat it must be payed to abandon the principle for the opposite vertex.

The component coupling principles are:

  • (ADP) The Acyclic Dependencies Principle: The principle states that should have no cycle into the component dependency graph, the dependency graph should be a DAG (Directed Acyclic Graph). Solutions to eliminate dependencies cycles are: apply the Dependencies Injection Principle (DIP) or create a new component that will contain the classes that other components are depending on.
  • (SDP) The Stable Dependencies Principle: This principle states that modules that are intended to be easy to change should not be dependent on by modules that are harder to change. The component stability metric, called I (for instability) is computed in the following way: I = Incoming dependencies / (Incoming dependencies + Outgoing dependencies). So SDP can be restated as :the  I metric of a component should be larger than the I metric of the components that it depends on, a component should depend on more stable components only.
  • (SAP)The Stable Abstraction Principle: For this principle, the author introduces a new metric called abstractness which is defined as follow: A = Number of classes in the component / Number of abstract classes and interfaces in the component.  A value of 0 implies that the component have no abstract classes, a value of 1 implies that the component contains only abstract classes. The SAP principle sets up a relationship between stability (I) and abstractness (A) that have the form of a graph:

Part V Architecture

This part of the book is made of 14 chapters (almost 120 pages) and treats different aspects of a good architecture: how to define appropriate boundaries and layers (“Boundary Anatomy” chapter, “Partial Boundaries” chapter, “Layers and Boundaries” chapter, “The Test Boundary”), how to make a system that is easy to understand, develop (“The Clean Architecture” chapter, “Presenters and Humble Objects” chapter), maintain and deploy, how to organize components and services (“Screaming Architecture” chapter).

It would be very difficult to resume 120 pages in few phrases but the most important take-away would be the characteristics of a system produced by a good architecture:

  • independent of any frameworks – must see the (technical) frameworks as tools and the architecture should not depend of this frameworks (“Screaming Architecture” chapter develops and argued more about this topic).
  • testable – the business rules of the system should be testable without any external element.
  • independent of the UI – the UI can change without affecting the use cases of the system.
  • independent of the database – the business rules/ use cases should not be bounded to any database.

Clean Architecture

The golden rule for a clean architecture is: Source code dependencies must point only inward toward higher-level policies; any item from a circle should know nothing about the items from outer circle/s. (see the following image).

For more information for the earlier concept of Clean architecture you can check the Uncle Bob initial blog post: The Clean Architecture.

Part VI Details

The last part of the book tries to explain why some of the (technological) items used in it projects like the database, the UI technology or (technical) frameworks should not influence/contaminate the system architecture and it should always be positioned at the outer circle (see the previous image). This part also has a case study on which some of the rules and thoughts about architecture are put together and applied.

 

(My) CSSLP Notes – Software Deployment, Operations, Maintenance and Disposal

Note: This notes were strongly inspired by the following books: CSSLP Certification All in one and Official (ISC)2 Guide to the CSSLP CBK, Second Edition

Installation and deployment

CSSLP-logoInstallation and deployment activities are implemented following a plan which can be used to document best practices. The software needs to be configured so that the security principles are not violated or ignored during the installation.

Some steps necessary in pre-installation or post-installation phases:

  • Hardening – Harden the host operating system by using the Minimum Security Baseline (MSB), updates and patches; also harden the applications and software that runs on top of the operating system.
  • Environment Configuration – pre-installation checklists are useful to ensure that the needed configuration parameters are properly configured.
  • Release Management – Release management is the process of ensuring that all the changes that are made to the computing environment are planned, documented, tested and deployed with least privilege without negatively impacting any existing business operations or customers.
    • Bootstrapping and secure startupBootstrapping (or booting) involves any one shot process that ensures the correctness of the initial configuration; this includes the the proper defaults and execution parameters. Secure startup refers to the entire collection of processes from the turning on of the power until the operating system is in complete control of the system.The use of TPM (Trusted Platform Module) chip enables significant hardening of startup parameters from tampering.

Operations and Maintenance

The purpose of the software operations process is to operate the software product in its intended environment; this implies a focus on the assurance of product effectiveness and product support for the user community.

The purpose of the software maintenance process is to provide cost-effective modifications and operational support for each of the software artifacts in the organizational portfolio.

Activities that are useful to ensure that the deployed software stays secure:

  • Monitoring – As part of the security management activities, continuous monitoring is critically important. The task is accomplished by: scanning, logging, intrusion detection.
  • Incident Management – The incident response management process applies whether the organization is reacting to a foreseen event or is responding to an incident that was not anticipated. The key to ensuring effective response is a well defined and efficient incident reporting and and handling process.
  • Problem ManagementProblem management is focus on improving the service and business operations. The goal of problem management is to determine and eliminate the root cause of an operational problem and in doing so it improves the service that IT provides to the business.
  • Change Management – Change Management includes also Patch and Vulnerability Management. The main goal of the change management is to protect the enterprise from the risk associated with changing of functioning systems.
  • Backup, Recovery and Archiving – In addition to regularly scheduled backups, when patches and software updates are made, it is advisable to perform full backup of the system that is being changed.

Secure Software Disposal

The purpose of the secure software disposal process is to safely terminate the existence of a system or a software entity. Like all formal IT processes, disposal is conducted according to a plan, that defines schedules, actions and resources.

Supplier Risk Assessment

The overall purpose of the supplier risk assessment is to identify and maintain an appropriate set of risk controls within the supply chain.

Categories of concerns for an external supplier:

  • installation of malicious logic in hardware or software.
  • installation of counterfeit hardware or software.
  • failure or disruption in the production of distribution of a critical product or service.
  • installation of unintentional vulnerabilities in software or hardware.

All the software items moving within a supply chain have to comply with existing laws and regulations.

(My) OWASP BeNeLux Days 2017 Notes – Training Day

These are my notes from the OWASP BeneLux Days 2017 on “Secure Development: Models and best practices” by Bart De Win.

The goal of the training was about how to improve the structure of an organization in order to enhance the security of (IT) applications.

The talk was around the following topics:

  • Software assurance maturity models
  • Introduction to SAMM and hands-on exercise/s
  • Secure Development in agile development
  • Tip and tricks for practical SDLC
  • Sneak preview of SAMM 2.0

Software assurance maturity models

Today we build more and more complex software:

  • multi platform;
  • mobile version; cloud
  • same application using different technological stacks

75% of vulnerabilities are application related

The state of the Secure Development LifeCycle (SDLC) today:

  • on focus on bugs not an (architectural) flows
  • (very often) do pen test just before going in live

The goal of  the SDLC is to develop and maintain software in a consisted and efficient way with  standards-compliance security quality.

SDLC Cornerstones:

  • peoples
  • process
    • activities
    • control gates
    • deliverables
  • knowledge
    • standards&guidelines
    • compliance
  • tools&component
    • development support
    • assessment tools
    • management tools

Introduction to SAMM and hands-on exercise

SAMM is an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks faced by an organization.

Other standards/frameworks that are in the same space as SAMM:

SAMM consists in 4 business functions each one containing 3 security practices. Each security practice have 4 maturity levels (from 0 to 3):

Each (SAMM) maturity level defines the following attributes:

  • objectives
  • activities
  • results
  • success metrics
  • cost
  • personnel
  • related levels

How do we start with SAMM: It is possible to start with the SAMM Toolbox Excel file in order to do an initial assessment for each of the  security processes (the Excel file will compute the maturity level). This initial assessment will help you to plan the improvements.

Secure Development in agile development

There are a mismatch between the agile development goal/s and the security goal/s

agile dev security
  • speed and flexibility
  • short cycles
  • limited documentation
  • functionality driven
  • stable and rigorous
  • extra activities
  • extensive analysis
  • non functional

Introducing security into agile development is not easy task and especially there is not a standardized way of doing it.

Some ideas and hints:

  • make security a natural part of the process
  • capture security requirements, policies and regulations in user stories

Sneak preview of SAMM 2.0

  • planned for end of next year.
  • model revision
  • more metrics
  • application to agile
  • benchmarking

(My) CSSLP Notes – Software acceptance

Note: This notes were strongly inspired by the following books: CSSLP Certification All in one and Official (ISC)2 Guide to the CSSLP CBK, Second Edition

CSSLP-logoSoftware acceptance is the life cycle process of officially or formally accepting new or modified software components, which when integrated form the information system.

Pre-Release activities:

  • completion criteria – are all the functional and security requirements completed as expected.
  • change management – is there a process in place to handle change requests.
  • approval to deploy/release – have all of the required authorities sign off.
  • risk acceptance and exception policy – is the residual risk acceptable or tracked as an exception.
  • documentation – are all the necessary documentation in place.

Post-Release activities:

  • validation & verification (V&V) Validation means that the software meets the specified user requirements.  Verification describes proper software construction. V&V is not an ad hoc process but it is a very structured and systematic approach to evaluate the software technical functionality. The evaluation can be divided in two main activities:
    • reviews
      • design (review).
      • code (review).
    • testing
      • error detection (tests).
      • acceptance (tests).
      • independent third party (tests).
  • certification and accreditationCertification is the technical verification of the software functional and assurance level. Accreditation is management’s formal acceptance of the system after an understanding of the risks to that system.

(My) BruCON 2017 Notes (2)

Here are my quick notes from the BruCON 2017 conference. All the slides can be found here.

How hackers changed the security industry and how we need to keep changing it

Back in the ’90 the hacker community was looked with suspicion by the software industry because the hackers were finding security problems and the software publishers had no process to handle this findings.

Back in the 90’s the only reference in order to create a secure system was the “Orange book“; but the orange book it’s all about security features, no word about bugs or vulnerabilities.

CERT – internet community had no means to fight against malware that’s why CERT was created. But the hacker community do not participate to CERT anymore because there was no traceability of the issues reported, so the Bugtraq was created.

Hackers created the concept of pen-test and the first (hacking) tools :

  • crack
  • satan (first network scanner)
  • netcat
  • NFT (first IDS)

The idea of securing the system by trying to break them was initially not very well welcomed by the industry.

In 2000 companies starts to hire hackers.
2002 – Microsoft Trustworthy computing – all the process of this initiative have been influenced by hackers

2003 (modern security era)

  • pen test became a requirement
  • companies create bug bounty programs

The idea that the security is an external process that is applied at the end is broken.
The security must be embedded in each part of the SDLC.

See no evil, hear no evil: Hacking invisibly and silently with light and sound

 The talk was about how the sound and light can be used to remotely extract information and was articulated around 3 parts:

  • jumping air-gaps
    • air-gap = computer isolated from the network; the goal is to make jump the air gap between the computer and the network in order to get exfiltrate data from the network.
    • ways of exfiltrate data from the network
      • screen luminosity; used to sent commands to an infected laptop, or used for data exfiltration.
      • near-ultrasonic sounds; same goals as the previous one
      • spectregram – embed images in sound files.
    • mitigation for jumping air-gaps
      • screen filters
      • disable luminosity sensors
      • disable microphones/speakers
  • surveillance and anti-surveillance
    • laser microphone – quite easy and cheap to make
    • sniffing and cloning the IR (infra-red) signals; used for bypassing the IR Motion detectors
  • funny things (done by the presentr)
    • Delayed Auditory Feedback (speech jamming) – the presenter build a software version.
    • Demotivating malware analysts –  create aspectregram and add it to a program that somebody will try to reverse it.
    • ultrasonic attack against drones

This is kind of mind-map of the talk:

XFLTReaT: a new dimension in tunnelling

This talk have 2 goals; the fists one is about building tunnels and the second goal is to present the XFLTReaT framework. Apparently the framework is very modular and very easy extensible.

XFLTReaT

  • tunneling framework
  • plug and play
  • modular
  • you do not have to take care by yourself about:
    • set up routing
    • handle multiple users
    • encryption

Client-Server approach; The client have a check functionality to find out which protocol is not filtered on the network.

 

(My) Brucon 2017 notes (1)

Here are my quick notes from the BruCON 2017 conference. All the slides can be found here.

Detecting malware when it is encrypted – machine learning for network https analysis

The goal is to find a way to detect malware using htps without decrypting the traffic.

Context:

  • 1/2 of the world wide Internet traffic is encrypted
  • 10%-40% of all malware traffic is encrypted
  • the encryption interferes with the efficacy of classical detection techniques

Some solutions to the problems:

  • TLS inspection; basically is the reverse proxy which is in the middle between the server and the client
    • advantage – can use the classical detection method
    • drawback – proxy server is expensive.
    • drawback – computationally demanding
  • try to find with no HTTPS decryption

Detect malware with no HTTPS decryption

Dataset used:

Used the pro ids product to capture different logs:

  • connection.log/s
  • ssl.log/s
  • x509.log/s

All this logs will be aggregated in order to create ssl aggregations and then generate a ssl-connect-units (each ssl-connect-unit represents a SSL connection). Each ssl-connect-unit have a source IP, destination IP, destination port, protocol and other 40 features (properties) like number of packages, number of bytes, number of different certificates, ratio of established and not established states .

A data set was created from all this ssl-connection-units and machine learning algorithms have been used against this dataset.

(ML) Algorithms used

  • XGBoost (Extreme Gradient Boosting)
  • Random forest
  • Neural network
  • svm

After using all this ML algorithms the features that have been identified as the most important ones to detect malware traffic:

  • certificate length of validity
  • inbound and outbound packets
  • number of domains in certificate
  • ssl/tls version
  •  periodicity

 

Knock Knock… Who’s there? admin admin and get in! An overview of the CMS brute-forcing malware landscape.

The talk was about malware brute force attacks of WordPress web sites which is the most used CMS product.

historical overview of the brute-force malware

2009 – first distributed brute force attack against WordPress
2013 – firstDisco also isntalled backdoors in the system
2014 – Mayhem
2015 – Aetra
2015 – CMS Catcher
2015- Troldeshkey
2017 – Stantinko

deep dive of SATHURBOT malware

modular botnet , 4 modules:

  • backdoor module
  • crawling module
  •  brute force module

Evading Microsoft ATA for Active Directory Domination

Microsoft ATA

  • Microsoft Advanced Threat Analytics
  • a product that detects attacks by reading traffic
  • how is deployed; an ATA gateway that intercepts the traffic

Threats detected by ATA:

  • recon
  • compromised credentials
  • lateral movement
  • domain dominance

Evading ATA :

  •  not poking the DC (Domain Controller) is the key
  • If you can’t bypass it then ovoid it by minimal talk with the DC

Atacking ATA deployment:

  • ATA console can be identified with basic banner grabbing.

Secure channels: Building real world crypto systems

What are secure channels – goal is to guarantee the confidentiality and integrity of data travelling over untrusted network.

objectives of a secure channel:

  • confidentiality
  • integrity establishment
  • authenticity

Constructing a secure channel:

  • need a way to exchange keys; keys establishment protocol
  • need a key derivation phase

Secure channel protocol design phases :

  • channel establishment
  • key establishment
  • secure data transfer
  • finish the protocol

How to build efficient security awareness programs

Some quotes from the talk:

  • Security problems are arising where more than one security technology are overlapping.
  • Stop trying to fix human behavior with tech only;maybe that are other ways to fix that.
  • Security isn’t always a business problem, but it’s always a human problem.
  • Tools to fix the human factor in security:
    • Fear
    • Incentives
    • Habits
      • trigger
      • routine
      • reward
      • repeat

Open Source Security Orchestration

Context:

  • multiple cloud severs, all using same Fail2ban jail.
  • How can make the different servers communicate.

In security operations most of the workflows are manual despite of multitude of solutions.
Different scenarios on which the automation could help a lot:

  • firewall role propagation scenario
  • drop propagation scenario
  • prevent known threats scenario
  • capture threat activity scenario

How to do the orchestration: using Adaptive Network Protocol (ANP)

  • developed so that nodes can share event information with each other
  • needed an ANP agent installed on each node.

How to create and customize a Docker image for Burp Suite Professional Edition

This ticket explains how to create and customize a Docker image for the Burp Suite Professional Edition. The main difference with a creation of an image for the Burp Suite Free Edition is that you will need to register a valid license during the image creation.

    • Create a Dockerfile for the initial image. You will need to have the burpsuite_pro_Vx.y.z jar file; the jar should be in the bin folder that is on the same level as the Dockerfile. The Docker file looks like this:
    FROM openjdk:8u121-jre-alpine
    RUN apk --update add openssl ca-certificates ttf-dejavu && \
        rm -f /var/cache/apk/* && \
        mkdir -p /opt/burp /work && \ 
        adduser -D -s /bin/sh user user && \
        chown -R user /work

    ADD bin/* /opt/burp/
    ADD config/ /home/user/
    RUN chown -R user /home/user/.*
    USER user
    WORKDIR /work
    EXPOSE 8080
  • Build the image:
    docker -t buildpro .
  • Run the image. It will be needed to run the Burp in the UI mode in order to register the license and (eventually) to customize the application (like installing extensions); unfortunately it is not possible to install extensions directly from the command line, so you will have to do it manually.
    docker run -ti \
      -e DISPLAY=$DISPLAY \
      -v /tmp/.X11-unix:/tmp/.X11-unix\
    burppro \
       java -jar /opt/burp/burpsuite_pro.jar
  • Once you’ve finished the customization, commit the new image in order to save the changes made on the initial image.
    docker commit <burppro_container_id> burppro_with_license_with_extension
  • Run the new image (in headless mode).
    docker run -p8080:8080 -ti \
    burppro_with_license_with_extension \
      java -jar -Djava.awt.headless=true /opt/burp/burpsuite_pro.jar
Shlomi Zeltsinger

Blockchain made simple