Monday, August 22, 2022

NISTIR 8259 Series

    United States Congress passed a bill in December 2020, named the Internet of Things Cybersecurity Act and signed by the president into law, to institute minimum security requirements and standards for IoT devices owned or controlled by federal agencies. This piece of legislation instructs NIST to develop the criteria and guidelines needed for the framework and review and revise it every five years. Further, the law mandates federal agencies, their contractors, and subcontractors to comply with such a framework from NIST.

    The “NISTER 8259” Series of reports delivers guidance and specifies a collection of activities for IoT manufacturers and the involved third parties to follow from the very beginning to design, build, test, market, and support IoT devices for their customers. NISTIR 8259 series contains one draft and three final documents to help implement “SP 800-213 series” guidance and requirements. You can find an overview of the mentioned NIST documentation about IoT as follow:

  • SP 800-213 – Delivering overall guidance for federal agencies on the proper use and administration of IoT devices connected to their infrastructure and IT systems.
  • NISTIR 8259A & B – Harmonizing the activities defined in NISTIR 8259 illustrating a technical and non-technical core baseline and supporting activities that manufacturers should reflect in their products from the earliest design steps and production.
  • NISTIR 8259C – Defining an operational process to portray the path that explains how to incorporate baselines presented by NISTIR 8259A & B with industry’s standards or compliances to produce IoT devices that match customers’ requirements.
  • NISTIR 8259D – Providing the results of utilizing the NISTIR 8259C process in a particular market sector (federal government), helping manufacturers to consider the necessary conditions for this sector.

    The main takeaway from NIST guidelines and legislation’s mandates for the federal government is the reality of our increasing dependency on the fast-ever-growing information technology despite its vulnerabilities. The exponential presence of IoT devices and acceptance of them as part of our private lives and every corner of our houses had already gone too far. In contrast, there haven’t been real and adequate security measures in place. Connecting these devices to the federal government’s IT infrastructure without proper controls and constraints could be catastrophic. NISTIR 8259 is an excellent base to start and constantly improve for securing these devices. This framework’s approach to be applied and considered from planning, designing, and production, to selling and customer service make it more effective and proactive.

 

Reference:

Saturday, August 20, 2022

Red Teaming

    Red teaming could be traced back to the early 1800s and the invention of the modern wargame, known as "Kriegsspiel." It was a redesigned elaborating simulation of war to train officers, test and try different strategies and tactics, and study possible varied outcomes. In the early 1900s, Germany employed and improved wargaming and used it during the war, allowing it to be observed the benefit of its other armies and becoming part of most armies planning toolkits.    

    Applying Kriegsspiel simulation in today's cyber landscape to help with securing and safeguarding the organizations against cybercriminals called red teaming, which is proven to be beneficial in:

  • Organizational defense assessment
  • Identifying flaws within security posture
  • Testing incident response readiness and efficiency in case of an incident
  • Identifying vulnerabilities in the systems and addressing relevant risks and available mitigations

    Red team members' job is to compromise the target's security, infiltrate the system, avoid detection during penetration, exploit bugs within the infrastructure, and present a documented and detailed assessment of the security posture to the organization or its blue team.

    When it comes to addressing a more proactive security approach, a few terms come up and sometimes might be a source of confusion like Red Teaming, Ethical Hacking, and Penetration Testing. As we discussed, Red Teaming is a process of investigating and detecting vulnerabilities and security weaknesses within the system by employing the hackers or attackers' mentality and approach. With this in mind, and since read teams are part of a corporate body, then the process could also be called "Ethical Hacking."

    Penetration Testing is also a process of finding flaws and weaknesses in the defense mechanism and security capabilities before an adversary exploits them; however, compared with Red Teaming, pen-testing is a shorter process, with more pre-defined areas to work on, mostly done after deployments and more systematic approach.

 

Reference:

Friday, August 19, 2022

Threat Modeling in Architecture Design and Pen -Testing

    Thereat modeling is an enhanced and structured methodology to identify and illustrate an organization's potential threats and vulnerabilities, utilize countermeasures and facilitate optimized security. To perform threat modeling for an organization, we will need to have a comprehensive image and deeper understanding of its systems, services, processes, business models, and operations, which usually would be achieved in a few steps such as:

  • Identifying the organizational assets, recognizing the level of their value for the organization, and categorizing them
  • Identifying the asset's exposure, attack surface, and vulnerabilities
  • Identifying threats and attack vectors
  • Planning mitigation and prevention

    Threat modeling produces a systematic process with unquestionable advantages for the security posture of any organization and its maturity by reducing attack surface, highlighting threats and mitigations methods combined with prioritizing them based on the organization's priorities, and helping with designing incident response and recovery plans.

    The Common Vulnerability Scoring System (CVSS) is one of the threat modeling methodologies or frameworks that acts as a vulnerability metric system. CVSS categorizes the attributes and gravity or severity of the vulnerabilities and produces standardized numerical scores (from 0 to 10) to indicate the likelihood of the impact of each vulnerability on the organizations. CVSS score contains three sets of metrics: basic, temporal, and environmental. CVSS has introduced the third version of itself (V3) to address some of the previous versions' flaws and better serve the cybersecurity landscape.

     While threat modeling is proven to be crucial for a healthy security posture, there are still some common misconceptions about employing this methodology like: pen-testing and code reviewing could replace this framework, or applying threat modeling after deployment wouldn't be necessary, or on the opposite side some might think that threat modeling would be enough to secure the system and additional measures wouldn't be required.

     The misconception about pen-testing and threat modeling begs for more profound attention to this issue, their differences, and the benefit of employing both methods to construct a better security posture.

     Threat modeling is applying security measures from the start and designing phase to avoid or manage flaws at the early steps, while pen-testing will be utilized later during the development and staging phase to test the developed applications and their resilience. So, in a strong and healthy security posture, we will need to employ both to complete a comprehensive security practice.    

 

Reference:

 

Tuesday, August 9, 2022

Securing The Enterprise Using SDL

  

    The Security Development Lifecycle (SDL) contains a series of best practices intending to help software developers to create more secure applications by keeping them within security assurance and compliance and diminishing the amount and severity of possible vulnerabilities. Some of these best practices are:

·       Teams awareness programs and making security a persistent concern

·       Implementing patches or updating management

·       Employing routine compliance check and reporting policy

·       Applying risk assessment and threat modeling (Risk Management)

·       Defining security requirements in software design such as cryptography, third-party and open-source components cautionary steps, preapproval requirement for using tools, security testing procedures, and analysis.

    In order to apply the SDL practices to the process of software development, we need to know that typically there are six phases in most development workflow:

·       Concept & Planning

·       Architecture & Design

·       Implementation

·       Testing & fixing

·       Release & Maintenance

·       End of Life

    Organizations tend to choose and employ the SDL methodologies that have been tested/proven already. Each one of those comes with a series of recommended practices, which could be used as templates, and give the security team several options to review and employ one or a combination of few.  

    At "Marks & Travis Software Village," the SDL starts with defining the principal of a secure design and itemized plan to utilize and address the security issues from the first step at the "concept and planning" stage by reviewing the range of applicable security practices in developing a new application.

    At the "Architect & Design" stage, the SDL shows itself by potential threat modeling and adding countermeasures in response, third-party component tracking, and monitoring to ensure a secure design.

    The "implementation" stage of the software development at our company employs secure coding, static scanning, and code reviews to enhance this development phase and combine automated checking and manual assessments.

    The "Testing & Fixing" stage applies dynamic scanning, fuzzing, and pen-testing to the process to reduce security concerns and provide safeguards against known vulnerabilities.

    At the "Release & Maintenance" stage of the development, SDL would be applied by the application's environment management, incident response plan, and constant security checks to guarantee our team's most secure application in action possible.

    The "End of Life" stage requires SDL strategies such as data retention and data disposal to reduce unexpected risks and possible data breaches.

    In an overview of SDL implementation at "Mark & Travis Software Village," I believe we have reasonably achieved an acceptable degree of secure software development by forming secure coding rules, building security-oriented culture and awareness within the software designer teams, and defining our expectations from teams' outcomes.   

Reference:

·       https://www.microsoft.com/en-us/securityengineering/sdl/practices (Links to an external site.)

·       https://www.dataversity.net/how-you-should-approach-the-secure-development-lifecycle/# (Links to an external site.)

·       https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure-software-development/ (Links to an external site.)

·       https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure-software-development/ (Links to an external site.)

·       https://www.softkraft.co/secure-software-development-lifecycle/

 

Thursday, August 4, 2022

Cloud Misconfiguration,

 Predominant Cloud Vulnerability and Security Threat


    According to the National Security Agency (NSA), “misconfiguration of cloud resources remains the most prevalent cloud vulnerability,” which subsequently attackers with low or no sophistication could easily exploit and get access to the cloud data and resources. The threat of security misconfiguration hasn’t been slowing down. It keeps constantly growing because of more immigrations to the cloud, the rise of multi-cloud solutions, and the complexity associated with new solutions. According to the 2020 Verizon Data Breach Investigations Report (2020-DBIR), only hacking earned a higher ranking than misconfiguration errors, causing data breaches.

 

    One of the recent examples of misconfiguration victims is Accenture, an Irish American professional, and IT services company based in Dublin. In August 2021, Accenture was reported as the subject of a massive data breach as a result of unintentional misconfiguration and leaving four Amazon Web Services (S3) open and visible to the public containing hundreds of gigabytes of confidential API data, clients’ data, and security credentials, including approximately 40,000 passwords in plain text, internal encryption keys, and other sensitive information.  LockBit ransomware attackers were asking for 50 million dollars to unlock the data. Accenture claims they had refused to pay the ransom and were able to contain the breach. However, it’s been reported that attackers had published some of the data on the Dark Web already.

 

There are some simple steps to avoid such massive impacts such as:

  • Develop and implement security policies
  • Creating templets for services and their configurations
  • Security automation
  • Multistep configuration checking
  • Routine recheck and verification process

 

Reference:

Evolution of Open Source Intelligence (OSINT)

  and rising in modern investigation The genesis of OSINT [1] , as we know it, in the United States goes back to the 1940s and World War II ...