Cybersecurity controls are essential for ensuring information confidentiality, integrity, and availability. However, selecting the most effective controls to maximize return on investment (RoI) in cyber defense is a complex task involving numerous factors such as vulnerabilities, threat prioritization, and budget constraints. This paper introduces an innovative model and optimization techniques to select cybersecurity controls (CSC) for optimal risk mitigation, balancing residual risk, budget, and resiliency requirements. Our approach features the Security Control Grid (SCG) model, which automatically determines the necessary controls based on their security functions (Identify, Protect, Detect, Respond, and Recover), strategic placement within the cyber environment, and effectiveness at different stages of the attack kill chain. We formulate cybersecurity control decision-making as a multidimensional optimization problem, solving it using Satisfiability Modulo Theories (SMT). Additionally, we integrate a domain-specific language model that links CSCs with Common Vulnerabilities and Exposures (CVEs). This approach is implemented in the SCG solver tool, which generates scalable and robust CSC deployment plans that optimize cybersecurity RoI and maintain acceptable residual risk for large-scale enterprises.

Post-deployment monitoring (PDM) occurs in the late stages of a DevSecOps (DSO) pipeline. Its role in DSO is critical in providing feedback loops on system performance leading to desirable changes achieving long-term system and application sustainment. Containers are the de-facto deployed artifacts in DSO for diverse forms of systems and applications including AI models. Long-term sustainment of containerized AI models requires appropriate metrics for the successful maintenance of optimal container and model computing performance and correct model inference. There is no agreed upon set of metrics that should always be present when monitoring a deployed containerized AI model. The current literature and practice can benefit from a standard baseline of metrics for long-term monitoring of containerized AI models focused on computing and inference. In this paper, we propose a candidate baseline of metrics for consideration as a standard across PDM for any containerized AI model. We present a proof-of-concept (PoC) that implements a baseline of metrics for the continuous monitoring of an operationally deployed containerized AI model. The baseline represents the minimal metrics required for any containerized model deployed and actively operating to ensure successful long-term monitoring and support of optimal operation and performance. The metrics focus on container operation, model operation, and model inference. This paper also details the raw data required for the metrics along with a PoC which demonstrates container engineering for their acquisition. The paper illustrates the baseline as a mix of dynamic metrics that are customized for each problem class (e.g., object detection, regression) and data modality together with static metrics that should be present for any containerized model. The paper further shows that a containerized AI model can be engineered to produce these metrics and describes the benefits of a standardized baseline of metrics to aid in the reduction of power consumption in the global digital enterprise.

In this experiential paper, we present observations from our collaborative efforts with multiple entities operating in highly regulated environments that enabled or disrupted the construction, use, and sustainment of secure CI/CD pipelines as part of a larger DevSecOps strategy. From these observations, we provide insights and recommendations to support enablers and avoid or minimize disruptions. Our insights reveal that along with noted established progress in the area of secure pipelines, there still exists a need to amend multiple cultural and technical barriers to fully realize secure pipelines in a highly regulated environment. Areas of improvement include streamlining security approvals, revising and updating polices to relevance with current technology, increasing automation in multiple pipeline relevant tasking, improving inquiries to better understand pipeline requirements at commencement, and ensuring appropriate sustained training of technical staff. Recommendations presented here address observed gap areas with the purpose of assisting further advancement of achieving formal and refined pipeline incorporation in a highly regulated environment.

Over the last decade, DevSecOps principles have gained widespread acceptance, replacing many traditional approaches to software development. DevSecOps has helped developers shorten the overall software development life cycle, and as a result, decreased the time to market. Following the broad success of DevSecOps, the next logical progression is to apply DevSecOps principles to other fields to achieve similar results, such as embedded systems. While embedded systems practices may stand to benefit greatly from the inclusion of DevSecOps principles, the field offers many new and unique challenges that have not been faced with traditional software systems. Existing DevSecOps frameworks cannot simply be applied to embedded systems. It is necessary to adapt current DevSecOps frameworks specifically to embedded systems. This piece will first lay out current DevSecOps principles and their application to software systems. Then, an empirical examination of existing work on DevSecOps in embedded systems will be presented. The required components of a DevSecOps framework that have been excluded from previous research will be highlighted, and from this, future areas of research in DevSecOps for embedded systems will be presented. The goal of this work is to summarize and analyze the current state of knowledge on DevSecOps in embedded systems and outline a path for future research.

This work presents lessons learned from a multi-year support effort of a large and well-funded software development project. The focus is on the security impacts to the DevSecOps culture, process, and pipeline. These impacts stem from faulty implementations of requirements in order to achieve a full DevSecOps environment. The faulty implementations resulted in a lax security posture facilitating potential compromise in many areas of the software development environment. We discuss each of the faulty implementations in detail and provide recommendations to avoid in future engagements. The main lesson learned was the organization's inability to strictly adhere to DevSecOps principles resulted in a dysfunctional software development environment and a reduced security posture.

As there are growing number of mobile devices worldwide, the applications running on the mobile hand-helds have great impact on the human life. One of the biggest factors for the usage of mobile applications is security and privacy since there are lots of personal and sensitive information for the individuals which are stored in these mobile devices. Because the mobile devices interact with many other devices and run on different kinds of communication protocols, the complexity and integration of mobile applications with the other digital entities increases much more ever than before. That is the reason the security and privacy issues for the mobile clients should be considered in very early steps of their application development phase which is exactly the analysis and design steps. In this study some of the security and privacy by design methodologies and toolsets have been explored. In the phase of UML modelling and workflow definition parts of the application development life cycle, some appropriate techniques have been used. From early stages of designing to test case generation and test execution steps have been covered, so that end to end secure mobile application development life cycle has been realized.

Secure DevOps has become a standard option for entities seeking to streamline and increase comprehensive participation by all stakeholders in their secure Security Development Lifecycle (SDLC)[1]. In most case in industry, academia, and government, applying DevOps is a straight forward process. There is a subset of entities in these three sectors where applying Secure DevOps is challenging. These are entities that are highly regulated (HRE) as mandated by policies for various reasons, the most often being general security and protection of intellectual property. Even if an entity is highly regulated, its secure SDLC can still benefit from implementing DevOps as long as the implementation does not break any policy[2].