Read Time:3 Second
IT leaders fear fragmented tech management could increase cyber risk
Category Archives: News
PureVPN introduces quantum-resistant feature to enhance security, tackle threats
Read Time:25 Second
Virtual private network (VPN) provider PureVPN has introduced a quantum-resistant feature to its OpenVPN protocol to provide users with more security and privacy for the post-quantum world. The firm has partnered with Quantinuum to deploy quantum-resistant encryption keys which, using its Quantum Origin platform, are generated via a verified quantum process, PureVPN said. The news comes as the security sector prepares for threats posed by the post-quantum encryption era.
Emotet tests new attack techniques: Sign of things to come?
Read Time:54 Second
Notorious threat group Emotet has been detected testing new and significantly different attack techniques potentially in preparation for larger campaigns or selective and limited attacks, according to research from cybersecurity vendor Proofpoint. The firm stated the activity occurred while the prolific botnet and Trojan threat actor was on a period of hiatus and not conducting its typical high-volume campaigns.
New Emotet attack activity a departure from typical behaviors
Emotet targets Windows platforms to distribute follow-on malware and was considered one of the most prolific cybercriminal threats before its disruption by global law enforcement in January 2021. After a 10-month disappearance from the threat landscape, the group re-emerged in November 2021 and has since targeted thousands of users in multiple geographic regions. In some cases, the volume of malicious messages used in individual campaigns has reached over one million, Proofpoint stated. However, activity detected between April 4 and April 19, 2022, signifies a significant departure from Emotet’s typical attack behaviors, and is attributed to threat actor TA542.
DevOps release process
Read Time:4 Minute, 49 Second
In the previous article, we covered the build and test process and why it’s important to use automated scanning tools for security scanning and remediation. The build pipeline compiles the software and packages into an artifact. The artifact is then stored in a repository (called a registry) where it can be retrieved by the release pipeline during the release process. The release process prepares the different components, including the packaged software (or artifacts) to be deployed into an environment. This article will cover the contents of a release and features within a release pipeline that prepare a release for deployment into an environment.
Artifact registry
Artifacts are stored in a registry (separate system from the code repository) and accessible by DevOps tools like release pipelines and the IT systems that the application will be deployed on to. Registries should be managed as an IT system and provided to the Development and DevOps teams as a service. The IT systems that support the registry should be hardened using the corporate security policies. The registry should be private and only accessible within the company if it is not intended to be a public source for artifacts. Password protection and IP whitelisting are also advised to ensure that packages can only be retrieved by approved systems. Logging information needs to be sent to a Security Operations Center (SOC) for monitoring. Encryption of the packages at rest and in transit is also required.
Contents of a release
A release is created by the release pipeline (Azure DevOps, Jenkins, Team City) and uses the artifacts created by a build pipeline. The release pipeline is triggered by the build pipeline and it knows attributes like the latest software version that was created and the name and location of the artifacts. The release pipeline is highly configurable depending on when the release should be scheduled to deploy, what variables and secrets (passwords, certificates, and keys) should be used, which version of the compiled code needs to be deployed, and approval processes to protect environments from having a release replaced without approvals.
Releases are capable of being automatically deployed onto IT systems when a new artifact version is built. DevSecOps best practice encourages automated builds but advises manual approval instead of automated releases to most environments. However, it may be appropriate for release pipelines to automatically deploy into a development environment that is under the development team control. Environments controlled by different teams like Quality Assurance (QA), User Acceptability Testing (UAT), Production, and Disaster Recovery (DR) typically do not have automated release pipelines after every new artifact version is built.
Variables and secrets are how running applications can be adapted to the different environments (development, QA, UAT, Production and DR). Variables are created in the pipeline tools and can be applied during the release pipeline. DevSecOps recommends storing secrets in a separate “key” vault that can be connected to the pipeline. Separate variables and secrets allow the software artifacts to remain the same no matter which environment they are deployed into. When the software is deployed, it looks for variables and secrets that were configured in the build and release processes and uses them to properly set the system up. Variables and secrets are a big reason why releases can be deployed so quickly and multiple times per day.
Version control is mandatory for knowing which version of software is being deployed, having a rollback plan to recover if there is a bug or issue, and keeping track of features and additions to the application as developers work on the code. Every time a build creates an artifact, a version number is applied. The version number is used by the release pipeline so that it knows which artifact to retrieve and deploy. DevSecOps recommends using the semantic versioning system for all artifacts.
Release pipelines have approval features that control the software release. At a minimum, approvals should be setup for each environment, or where separation of duties is required between the development team and other groups in the organization. For example, the QA group should be the only team who can grant approval to release and deploy into the QA environment. This is because QA teams may still be working through their test plans on an older release, and they need to finish before testing the new release.
Build and release agents
The two types of servers (IT) for build and release activities are vendor-hosted and self-hosted. Vendor-hosted agents are managed by the vendor so upgrades and maintenance or taken care of. Also, a new agent is provided every time the build or release pipelines are run. This makes resource management easy for the company but may not be an option for unique build and deploy dependencies. While extremely secure, builds and releases performed by vendor-hosted servers are not in the company’s control.
Self-hosted agents are managed by the company and require the systems to be upgraded, maintained and any dependencies be installed before the agents can be used in build and release activities. Self-hosted agents work well when the DevOps platforms are internally hosted and not using any cloud-based servers. For example, self-hosted Jenkins pipelines use self-hosted servers and remain completely private and in the control of IT.
Next steps
There are many moving parts and components to the release process that need to be architected and designed with security in mind. The parts and components overlay with multiple vendors, all of the different environment owners, security, and IT. This requires the different members of a DevOps team, spread across all the different organizations, to work together and deliver changes to business systems safely and securely. The next article covers how a release is deployed and operated securely
Security Teams Should Be Addressing Quantum Cyber-Threats Now
Read Time:4 Second
Organizations should move toward post-quantum cryptography now to counter upcoming quantum cyber-threats
Two More Indicted Over North Korea Sanctions Evasion Plot
New SDP 2.0 specification facilitates zero-trust maturity
Read Time:29 Second
The Cloud Security Alliance (CSA) recently published the Software-Defined Perimeter (SDP) 2.0 specification, which is created by their SDP and zero-trust working groups. Given that the original specification was published in 2014 and we’ve seen industry-wide eagerness to adopt zero trust, this update is timely. SDP ties closely to the pursuit of implementing a zero-trust architecture, and what follows are the key aspects of SDP 2.0 in zero-trust environments that CISOs and other security leaders need to know.
The cloud security emperor has no pants
Read Time:37 Second
As anyone who has worked on a cross-functional team with no clear owner knows, “shared” or “joint” responsibility often means that everyone assumes that someone else is taking care of the problem. Without clear effort to make sure that nothing falls between the two (or more) teams, something always gets missed.
The shared responsibility model and cloud service providers
The cloud services “shared responsibility” model goes something like this: the cloud provider protects everything below a certain level (that level generally being their software) and is responsible for securing it. Consider that the foundation of your house. You, the customer, are responsible for protecting everything above the foundation—securing the house, if you will.
French Hospitals Cut Internet Connection After Data Raid
Ransomware attack attempted to destabilise Costa Rica, says outgoing president
Read Time:13 Second
Costa Rica’s outgoing president, Carlos Alvarado Quesada, has said that a ransomware attack on the government’s computer systems was an attempt to destabilise the country as it transitions to a new administration.
Read more in my article on the Hot for Security blog.