US Execs Tout Retaliation Over Diplomacy

US Execs Tout Retaliation Over Diplomacy

Business executives in the United States favor retaliatory action over diplomacy when it comes to preventing cyber-attacks. 



A day after American president Joe Biden announced his intention to replace “relentless war” with “relentless diplomacy,” new research by Arctic Wolf shows that just 15% of US executives believe that diplomacy effectively stops future cyber-attacks. 



More than twice as many US executives – 31% – believe that retaliatory cyber-attacks against foreign nations would be effective in putting a halt to digital assaults.  



When asked which countries posed the most serious threat to their business, 41% of IT decision makers pointed the finger at China while another 41% named Russia. 



The research is based on a survey of more than 1,400 senior IT decision makers and business executives in Canada, the UK, and the US that took place in August. 



“Survey respondents revealed that despite recent interventions into cybersecurity issues, they lack faith in the government’s ability to protect them from cyber-threats, with 60% of organizations believing that spending on new security tools and services is the most effective way of stopping attacks,” stated Arctic Wolf’s Ian McShane.



This lack of confidence extended to the respondents’ own ability to secure hybrid work environments, with 60% of executives stating that their individual employees wouldn’t be able to identify a cyber-attack targeting their business in any working location. 



Another key finding of the report was that most C-suite executives in Canada, the UK, and the US said that they would pay a ransom to their cyber-attackers.



The survey found that only 22% of C-suite executives, when asked if they would pay a ransom if their organization were hit by a ransomware attack, answered “never.” When the same question was posed to middle managers, more than half (56%) gave “never” as their response. 



Nearly a third of the organizations surveyed (32%) reported suffering a data breach that exceeded six figures in the past year, with most business owners (61%) admitting that they had personally concealed a breach. 



Asked if their organization had deliberately covered up a cyber-attack to prevent the reputation of their organization’s being blemished, one in five respondents admitted that it had.



Source: Infosecurity
US Execs Tout Retaliation Over Diplomacy

#IMOS21: Alyssa Miller's Advice for Building a Successful Infosecurity Career

#IMOS21: Alyssa Miller’s Advice for Building a Successful Infosecurity Career

Cybersecurity professionals need to shoot for the stars and overcome self-confidence issues to progress in their careers. That was the message of an illuminating keynote address by Alyssa Miller, business information security officer, SMP Global, while giving the keynote address at the Infosecurity Magazine Autumn Online Summit – North America 2021.


Miller began by describing her own career to date, and how she reached the heights of business information security officer at SMP Global, where she leads the cybersecurity strategy for a $4bn a year division.


Her career in information security began at 19 as a programmer at a fintech firm, while she was still studying computer science at university. She stayed at the firm for almost nine years, holding a range of high-profile positions.


At 28, Miller was approached to become a penetration tester; while she was concerned she had no prior knowledge of penetration testing, she was assured she would be able to figure it out. This leap worked, as by the age of 31 Miller was leading a team alongside the entire testing and vulnerability management program for a 35,000 employee company. Despite these achievements, Miller continued to consider her progression as mainly luck. “I never really considered how impressive some of that was,” she explained.


Four years later, at the age of 35, Miller entered the world of consultancy in an application security practice. As the least profitable practice at the consultancy, she was tasked with building a team from the ground up and alongside colleagues, made that team the most profitable in the entire practice, achieving revenue growth of 400%. However, “I never really gave myself a lot of credit for that,” she reflected. 


Following a merger, Miller became head of a program services practice of a new consulting services firm at the age of 37, where she worked with high-ranking security leaders like CIOs and CISOs in major global organizations. Again, Miller largely put this down to “serendipity.”  


Then, a setback occurred at the age of 41 while working for a security consulting organization as part of a larger security practice at a reseller. She was passed over for promotion to director despite being the pick of the previous director. “It really harmed my self-confidence. I felt like I’d shot too high, maybe I wasn’t ready for that high level of a role,” she outlined.


This led her to re-evaluating her goal of progressing in high-level security positions, and she moved into a ‘contributor’ role, focusing on public speaking and advocacy work.


Her perspective changed when she was approached by one of the three big social media companies, who asked if she’d like to be considered for an executive position. While nobody was ultimately hired for that role, just being considered “forced me to go back and look at everything I’d done and ask ‘why did they choose me?’” This made her analyze the extent of her achievements “and it really built up my self-confidence.”


This new found confidence took Miller to her current high-profile position, as BISO for SMP Global. “This is a chance now to do all those things I’ve been working towards all my life — what an exciting position to be in,” she said, adding: “I’d never have gotten here if I’d been afraid to take that leap, if I’d let that damage to my self-confidence hold me back.”

“This is a chance now to do all those things I’ve been working towards all my life — what an exciting position to be in”Alyssa Miller

Miller believes that getting over self-confidence issues is therefore key to progressing security careers, especially for women, who she believes continue to experience numerous disadvantages in the workplace. This includes being expected to give up their careers for their families.


With this in mind, Miller gave the following advice to those keen to develop in their careers:


  • Overcome “imposter syndrome” — the fear of being ‘found out’ in a role is “universally experienced,” particularly in tech. Therefore, it is worth remembering that there is a wide domain of cybersecurity knowledge that is around, meaning each person brings their own unique diverse perspective to the table. “Nobody knows it all,” Miller pointed out.
  • Look at job descriptions differently — Miller said that in cyber, many job descriptions “stink,” setting out experiences, requirements and responsibilities that are simply unrealistic. She gave one example of a job description that required 10 years of experience of Kubernetes, even though it has only existed for six. However, she advised potential candidates to not be put off “as no-one can check off all those boxes,” and instead look at the high level job description and ask themselves “is this something you can do or something you can learn to do?”
  • Know your worth Potential employers should never ask you what your current salary is, and if they do, you should turn the question round and tell them what you expect to be paid or even what they expect to pay someone to do that job, Miller advised. She added that you can look on sites like LinkedIn and Glassdoor to give yourself a better idea of what kind of salary you should be earning for the position you are applying for. This way, you can ensure you will be paid what you are worth to that organization.
  • Get a mentor — Miller also advised people to get a mentor to help guide them on their career journey. Rather than focusing on learning job skills, the mentor “should be sharing their journey, and be that person to help [with] situations you’re experiencing that you need help understanding or navigating.” This relationship is best forged “organically” via people met at work or at conferences.
  • See denials differently — People need to ensure they do not lose confidence if they are not offered a job after attending an interview, said Miller. The decision is never a personal one, and it might just be that “there was something about that role that wasn’t right for you.” She added that it is always worth asking for feedback from the hiring manager about what they could have done differently with their resume or during the interview. “You can use these denials as an opportunity to grow and learn, to understand how a certain position might not be the right fit for you.”
  • Negotiate the job offer — It is also important to understand that any job offer you do receive is negotiable, and don’t be afraid the company will rescind the offer if you do try and negotiate the terms of the deal. This is something that recruiters expect, noted Miller. This negotiation doesn’t just have to revolve around salary either, and can include aspects like bonuses and annual leave. “Always be willing ask, don’t be afraid,” she said.

Miller concluded by saying: “Shoot for those heights – just because you shoot high doesn’t mean that you have a chance of falling.”


Source: Infosecurity
#IMOS21: Alyssa Miller’s Advice for Building a Successful Infosecurity Career

CVE-2021-40684

Talend ESB Runtime in all versions from 5.1 to 7.3.1-R2021-09, 7.2.1-R2021-09, 7.1.1-R2021-09, has an unauthenticated Jolokia HTTP endpoint which allows remote access to the JMX of the runtime container, which would allow an attacker the ability to read or modify the container or software running in the container.
Source: NIST
CVE-2021-40684

CVE-2021-37860

Mattermost 5.38 and earlier fails to sufficiently sanitize clipboard contents, which allows a user-assisted attacker to inject arbitrary web script in product deployments that explicitly disable the default CSP.
Source: NIST
CVE-2021-37860

CVE-2019-6288

Edgecore ECS2020 Firmware 1.0.0.0 devices allow Unauthenticated Command Injection via the command1 HTTP header to the /EXCU_SHELL URI.
Source: NIST
CVE-2019-6288

Distroless Builds Are Now SLSA 2

A few months ago we announced that we started signing all distroless images with cosign, which allows users to verify that they have the correct image before starting the build process. Signing our images was our first step towards fully securing the distroless supply chain. Since then, we’ve implemented even more accountability in our supply chain and are excited to announce that distroless builds have achieved SLSA 2. SLSA is a security framework for increasing supply chain security, and Level 2 ensures that the build service is tamper resistant.

This means that in addition to a signature, each distroless image now has an associated signed provenance. This provenance is an in-toto attestation and includes information around how each image was built, what command was run, and what build system was used. It also includes any special parameters that were passed in, the exact commit the images were built at, and more. This provenance is a useful tool for builds that need to be audited in the future.

SLSA 2 Requirement

Distroless

Source – Version controlled

Source code in Github

Build – Scripted build

Build script exists as a Tekton Pipeline, invoked as a Google Cloud Build step

Build – Build service

All steps run on Kubernetes with Tekton

Provenance – Available

Provenance is available in the rekor transparency log as an in-toto attestation

Provenance – Authenticated

Provenance is signed with the distroless GCP KMS key

Provenance – Service generated

Provenance is generated by Tekton Chains from a Tekton TaskRun


Achieving SLSA 2 required some changes to the distroless build pipeline: we set up Tekton Pipelines and Tekton Chains in a GKE cluster to automate building images and generating provenance. Every time a pull request is merged to the distroless Github repo, a Tekton Pipeline is triggered. This Pipeline builds the distroless images, and Tekton Chains is responsible for generating signed provenance for each image. Tekton Chains stores the signed provenance alongside the image in an OCI registry and also stores a record of the provenance in the rekor transparency log.

Don’t trust us?

You can try the build yourself. Because distroless builds are reproducible, all the information to replicate the build is in the provenance, and you or a trusted third party can build the image yourselves and verify the build is correct by matching image digests.

You can verify an attestation for a distroless image with cosign and the distroless public key:

$ cosign verify-attestation -key cosign.pub gcr.io/distroless/base@sha256:4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91

Verification for gcr.io/distroless/base@sha256:4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91 —

The following checks were performed on each of these signatures:

  – The cosign claims were validated

  – The signatures were verified against the specified public key

  – Any certificates were verified against the Fulcio roots.

And you can find the provenance for the image in the rekor transparency log with the rekor-cli tool. For example, you could find the provenance for the above image by using the image’s digest and running:

$ rekor-cli search –sha sha256:4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91

af7a9687d263504ccdb2759169c9903d8760775045c6e7554e365ec2bf29f6f8

$ rekor-cli get –uuid af7a9687d263504ccdb2759169c9903d8760775045c6e7554e365ec2bf29f6f8 –format json | jq -r .Attestation | base64 –decode | jq

{

  “_type”: “distroless-provenance”,

  “predicateType”: “https://tekton.dev/chains/provenance”,

  “subject”: [

    {

      “name”: “gcr.io/distroless/base”,

      “digest”: {

        “sha256”: “703a4726aedc9ec7a7e32251087565246db117bb9a141a7993d1c4bb4036660d”

      }

    },

    {

      “name”: “gcr.io/distroless/base”,

      “digest”: {

        “sha256”: “d322ed16d530596c37eee3eb57a039677502aa71f0e4739b0272b1ebd8be9bce”

      }

    },

    {

      “name”: “gcr.io/distroless/base”,

      “digest”: {

        “sha256”: “2dfdd5bf591d0da3f67a25f3fc96d929b256d5be3e0af084db10952e5da2c661”

      }

    },

    {

      “name”: “gcr.io/distroless/base”,

      “digest”: {

        “sha256”: “4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91”

      }

    },

    {

      “name”: “gcr.io/distroless/base”,

      “digest”: {

        “sha256”: “dc0a793d83196a239abf3ba035b3d1a0c7a24184856c2649666e84bc82fc5980”

      }

    },

    {

      “name”: “gcr.io/distroless/base-debian10”,

      “digest”: {

        “sha256”: “2dfdd5bf591d0da3f67a25f3fc96d929b256d5be3e0af084db10952e5da2c661”

      }

    },

    {

      “name”: “gcr.io/distroless/base-debian10”,

      “digest”: {

        “sha256”: “703a4726aedc9ec7a7e32251087565246db117bb9a141a7993d1c4bb4036660d”

      }

    },

    {

      “name”: “gcr.io/distroless/base-debian10”,

      “digest”: {

        “sha256”: “4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91”

      }

    },

    {

      “name”: “gcr.io/distroless/base-debian10”,

      “digest”: {

        “sha256”: “d322ed16d530596c37eee3eb57a039677502aa71f0e4739b0272b1ebd8be9bce”

      }

    },

    {

      “name”: “gcr.io/distroless/base-debian10”,

      “digest”: {

        “sha256”: “dc0a793d83196a239abf3ba035b3d1a0c7a24184856c2649666e84bc82fc5980”

      }

    },

    {

      “name”: “gcr.io/distroless/base-debian11”,

      “digest”: {

        “sha256”: “c9507268813f235b11e63a7ae01526b180c94858bd718d6b4746c9c0e8425f7a”

      }

    },

    {

      “name”: “gcr.io/distroless/cc”,

      “digest”: {

        “sha256”: “4af613acf571a1b86b1d3c50682caada0b82024e566c1c4c2fe485a70f3af47d”

      }

    },

    {

      “name”: “gcr.io/distroless/cc”,

      “digest”: {

        “sha256”: “2c4bb6b7236db0a55ec54ba8845e4031f5db2be957ac61867872bf42e56c4deb”

      }

    },

    {

      “name”: “gcr.io/distroless/cc”,

      “digest”: {

        “sha256”: “2c4bb6b7236db0a55ec54ba8845e4031f5db2be957ac61867872bf42e56c4deb”

      }

    },

    {

      “name”: “gcr.io/distroless/cc-debian10”,

      “digest”: {

        “sha256”: “4af613acf571a1b86b1d3c50682caada0b82024e566c1c4c2fe485a70f3af47d”

      }

    },

    {

      “name”: “gcr.io/distroless/cc-debian10”,

      “digest”: {

        “sha256”: “2c4bb6b7236db0a55ec54ba8845e4031f5db2be957ac61867872bf42e56c4deb”

      }

    },

    {

      “name”: “gcr.io/distroless/cc-debian10”,

      “digest”: {

        “sha256”: “2c4bb6b7236db0a55ec54ba8845e4031f5db2be957ac61867872bf42e56c4deb”

      }

    },

    {

      “name”: “gcr.io/distroless/java”,

      “digest”: {

        “sha256”: “deb41661be772c6256194eb1df6b526cc95a6f60e5f5b740dda2769b20778c51”

      }

    },

    {

      “name”: “gcr.io/distroless/nodejs”,

      “digest”: {

        “sha256”: “927dd07e7373e1883469c95f4ecb31fe63c3acd104aac1655e15cfa9ae0899bf”

      }

    },

    {

      “name”: “gcr.io/distroless/nodejs”,

      “digest”: {

        “sha256”: “927dd07e7373e1883469c95f4ecb31fe63c3acd104aac1655e15cfa9ae0899bf”

      }

    },

    {

      “name”: “gcr.io/distroless/nodejs”,

      “digest”: {

        “sha256”: “f106757268ab4e650b032e78df0372a35914ed346c219359b58b3d863ad9fb58”

      }

    },

    {

      “name”: “gcr.io/distroless/nodejs-debian10”,

      “digest”: {

        “sha256”: “927dd07e7373e1883469c95f4ecb31fe63c3acd104aac1655e15cfa9ae0899bf”

      }

    },

    {

      “name”: “gcr.io/distroless/nodejs-debian10”,

      “digest”: {

        “sha256”: “f106757268ab4e650b032e78df0372a35914ed346c219359b58b3d863ad9fb58”

      }

    },

    {

      “name”: “gcr.io/distroless/nodejs-debian10”,

      “digest”: {

        “sha256”: “927dd07e7373e1883469c95f4ecb31fe63c3acd104aac1655e15cfa9ae0899bf”

      }

    },

    {

      “name”: “gcr.io/distroless/python3”,

      “digest”: {

        “sha256”: “aa8a0358b2813e8b48a54c7504316c7dcea59d6ae50daa0228847de852c83878”

      }

    },

    {

      “name”: “gcr.io/distroless/python3-debian10”,

      “digest”: {

        “sha256”: “aa8a0358b2813e8b48a54c7504316c7dcea59d6ae50daa0228847de852c83878”

      }

    },

    {

      “name”: “gcr.io/distroless/static”,

      “digest”: {

        “sha256”: “9acfd1fdf62b26cbd4f3c31422cf1edf3b7b01a9ecee00a499ef8b7e3536914d”

      }

    },

    {

      “name”: “gcr.io/distroless/static”,

      “digest”: {

        “sha256”: “e50641dbb871f78831f9aa7ffa59ec8f44d4cc33ae4ee992c9f4b046040e97f2”

      }

    },

    {

      “name”: “gcr.io/distroless/static-debian10”,

      “digest”: {

        “sha256”: “9acfd1fdf62b26cbd4f3c31422cf1edf3b7b01a9ecee00a499ef8b7e3536914d”

      }

    },

    {

      “name”: “gcr.io/distroless/static-debian10”,

      “digest”: {

        “sha256”: “e50641dbb871f78831f9aa7ffa59ec8f44d4cc33ae4ee992c9f4b046040e97f2”

      }

    }

  ],

  “predicate”: {

    “invocation”: {

      “parameters”: [

        “MANIFEST_SUBSECTION={string 0 []}”,

        “CHAINS-GIT_COMMIT={string 976c1c9bc178ac0371d8888d69893145c3df09f0 []}”,

        “CHAINS-GIT_URL={string https://github.com/GoogleContainerTools/distroless []}”

      ],

      “recipe_uri”: “task://distroless-provenance”,

      “event_id”: “531c282f-806e-41e4-b3ad-b596c4283381”,

      “builder.id”: “tekton-chains”

    },

    “recipe”: {

      “steps”: [

        {

          “entryPoint”: “#!/bin/shnset -exnn# get the digests for a subset of images built, and store in the IMAGES resultngo run provenance/provenance.go images $(params.MANIFEST_SUBSECTION) > $(results.IMAGES.path)n”,

          “arguments”: null,

          “environment”: {

            “container”: “provenance”,

            “image”: “docker.io/library/golang@sha256:cb1a7482cb5cfc52527c5cdea5159419292360087d5249e3fe5472f3477be642”

          },

          “annotations”: null

        }

      ]

    },

    “metadata”: {

      “buildStartedOn”: “2021-09-16T00:03:04Z”,

      “buildFinishedOn”: “2021-09-16T00:04:36Z”

    },

    “materials”: [

      {

        “uri”: “https://github.com/GoogleContainerTools/distroless”,

        “digest”: {

          “revision”: “976c1c9bc178ac0371d8888d69893145c3df09f0”

        }

      }

    ]

  }

}

As you might guess, our next step is getting distroless to SLSA 3, which will require adding non-falsifiable provenance and isolated builds to the distroless supply chain. Stay tuned for more!


Source: Google
Distroless Builds Are Now SLSA 2

CVE-2021-41011

LINE client for iOS before 11.15.0 might expose authentication information for a certain service to external entities under certain conditions. This is usually impossible, but in combination with a server-side bug, attackers could get this information.
Source: NIST
CVE-2021-41011

CVE-2021-40875

Improper Access Control in Gurock TestRail versions < 7.2.0.3014 resulted in sensitive information exposure. A threat actor can access the /files.md5 file on the client side of a Gurock TestRail application, disclosing a full list of application files and the corresponding file paths. The corresponding file paths can be tested, and in some cases, result in the disclosure of hardcoded credentials, API keys, or other sensitive data.
Source: NIST
CVE-2021-40875

CVE-2021-31836

Improper privilege management vulnerability in maconfig for McAfee Agent for Windows prior to 5.7.4 allows a local user to gain access to sensitive information. The utility was able to be run from any location on the file system and by a low privileged user.
Source: NIST
CVE-2021-31836

CVE-2021-31841

A DLL sideloading vulnerability in McAfee Agent for Windows prior to 5.7.4 could allow a local user to perform a DLL sideloading attack with an unsigned DLL with a specific name and in a specific location. This would result in the user gaining elevated permissions and the ability to execute arbitrary code as the system user, through not checking the DLL signature.
Source: NIST
CVE-2021-31841