devopsy.kinsta.cloud

Tag: compliance

How to Solve 3 Significant Development Challenges
As products, systems, and software grow in complexity, so does the development process. This can lead to an increased risk of flaws and can result in expensive and potentially reputation-harming mistakes or recalls.

These new complexities have shifted the product development process entirely, requiring optimization from end to end. Engineering and design teams need solutions that answer the most common challenges they face in this process. This means being provided purposeful, structured collaboration tools; connecting distributed team members; and accurately capturing and facilitating feedback, decision-making and context for requirements under review.

Navigating Development Challenges

To do this, teams developing complex products, systems and software must first overcome some significant obstacles. To help navigate this journey, let’s examine some of the most prominent product development challenges engineers are facing today.

Outdated Legacy or Document-based Solutions

The traditional approach to managing risks and requirements is highly manual, operating in an old mindset in which numerous spreadsheets and versioned documents are shared via email. This method has serious drawbacks, including no guarantee that data is up to date. This results in valuable time lost deciphering different versions or painstakingly making changes manually to achieve cross-team alignment.

Additionally, without a clear path of traceability—which can be difficult to achieve for those who rely on static documents—teams often end up referencing older and often outdated versions of requirements. This inevitably leads to misalignment, increased risk and costly rework.

The solution? Uplevel your traceability practices. Moving on from outdated legacy solutions to a modern requirements management tool is the first step to bolstering creativity, productivity and collaboration.

Compliance, regulations and standards processes

Product, systems and software development has become much more complicated over time. As a result, so has product risk and the accompanying regulatory compliance required.

To ensure the long-term success of organizations developing these complex systems, software and products, strong collaboration between teams, knowledge of applicable regulations and effective requirements management platforms are necessities. These tools provide a simple path and single source of truth for defining, verifying and validating key regulations. However, despite numerous industry studies indicating that requirements issues are a prominent factor of project distress, not everyone is convinced their team needs to focus on requirements development and management. Further, they’re unsure of how it will all pay off.

To address these challenges, companies need to streamline their quality and risk management strategies. This can be done by incorporating detailed traceability across the development life cycle—from the high-level user needs and systems requirements through to validation and verification.

Effective Review Cycles

Review cycles are often time-consuming and fragmented. For example, when approaching requirements management manually and with disparate documents, a cycle can be repeatedly delayed due to versioning issues and lack of a single source of truth updated in real-time. It also reduces team visibility throughout the review process; individuals end up spending hours per week in review meetings just to ensure everyone is on the same page.

To up-level this process, it’s necessary to have:
- One source of truth for requirements and tests.
- A straightforward way to send items such as requirements, user stories or test cases for review.
- Best practices for each major role involved clearly outlined (i.e., reviewer, approver, moderator).
- Real-time collaboration within a shared, dynamic requirements management platform.
- An outline of a formal approval process to capture and record sign-off.
Collaboration is Key to Development Success

At the end of the day, collaboration is at the core of all product development work. The ability to effectively work together is critical to ensure innovation doesn’t stop. In this era of rapidly accelerating change, structured and strategic team collaboration is the means for improving the product development process for all involved. By updating your legacy traceability solutions, establishing effective review cycles, and streamlining your regulations, compliance and standards processes, your team will be well on its way to a much more effective and unified product development process.
November 6, 2020
How to Secure Fintech Applications and Protect Customer Data
All industries are feeling the pain of preventing rising risks to their applications, private information and customers’ data, and it is not surprising that this is especially true in the financial services sector. In fact, fintech companies on average spent more than $18 million in 2019 battling cybercrime, while other markets’ companies spend an average of $13 million addressing cybersecurity concerns each year.

While these numbers can be depressing, a recent virtual roundtable we hosted with some of the best AppSec brains in fintech uncovered three steps organizations can take to secure their fintech applications and protect their customer data. The panel included Erick Lee, director of Security at Intuit; Jeremiah Kung, first vice president and global head of digital cybersecurity at East West Bank; and Karthik Rangarajan, security lead at Robinhood.

The panel discussed AppSec trends, best practices for what is working in their organizations and recommendations for security leader peers who are tasked with addressing application security at their organizations. The group agreed that there’s a lot of creative thinking and exciting work happening around AppSec, and that includes across all of DevOps and engineering, not just those charged with application security. These notions can’t help but leave one feeling optimistic.

While the spirited discussion covered a variety of topics and trends, here are the three high-level recommendations organizations should follow to best secure their fintech applications.
1. 1. Make sure AppSec teams are hiring software engineers. The panelists agreed that security and engineering functions should not operate as separate entities. One participant described why he hires software engineers instead of security engineers. He explained that software engineers know how to create fixes and operate at scale, which is critical for his organization, which manages 1.5 million requests per second. Since many organizations do not have the resources to hire a security engineer, particularly smaller and growing groups, it is especially important to build security into the engineering team.Organizations tend to discover scalable methods of solving problems and accelerating the development process when engineers are engaged with security. Take for example a security concern that delayed an application release. The panelists agreed that unless the issue is a show stopper, security should not delay a release, unless of course there is a compliance concern or potential violation. They recommended for developers do their thing, and let security work hard and try to keep up.
    The panelists explained this is because companies need to keep pace and release products and triage at scale. This is especially true in the fintech space, where winning business is about application features and capabilities. As an example, one panelist illustrated how his company’s focus is trying to ensure developers have paved roads so they can get “speed to benefit to customers.”
    
    To make this happen, his company deployed tools for automation, such as solutions that scan GitHub code for potential issues. They are also leveraging automation to monitor for security problems all through production. The punch line for them is to make security complementary and seamlessly woven into the workflow, it cannot be a secondary process slowing development.
    
    Compliance should be approached as an engineering problem. A significant challenge for financial services companies and fintech continues to be adhering to governance and compliance requirements. One of the reasons is a lack of automation and solutions that scale, which come at significant costs. In fact, one-third of global financial services companies spend more than 5% of their budget just on addressing compliance.Many financial services organizations rely on spreadsheets, PDFs, paper files and email chains to address and prove compliance. Fintech companies continue to address compliance questions using paper documentation and manual work. These methods are clearly not scalable and not sustainable for growing organizations to meet their expanding compliance demands.
    Fortunately, as the panelists uncovered, compliance and governance can be viewed through an engineering lens, as they have seen happen at some of the best fintech companies. One panelist illustrated that at his company he met with compliance experts to learn precisely about their problems, so his team could engineer solutions. After discovering the issues and metrics needed to prove compliance effectiveness, his team introduced automation and new tools to address the issues. His company knows the compliance methods are working if the metrics are being met, he said.
    
    Another panelist added that meeting regulatory compliance within a global organization like his introduces additional challenges of meeting compliance requirements in multiple jurisdictions. But the need to understand where data is and how it is being kept safe is common across the board. If you can address those questions, he said, then proving that the data is safe becomes the main task.
    
    For development and application security to remain sustainable, compliance cannot remain manual and human based. The panelists agreed that it’s unlikely to be able to fully automate all of the reporting and processes needed, but with a goal of 80% automation and 20% manual methods, organizations will be in a much better position.
    
    Security must be proactive. This is a common theme in our industry these days, and it certainly was popular thought the entire roundtable discussion. The panelists highlighted that fintech engineering teams are thinking about compliance and security in a variety of proactive ways. One panelist recalled that he asks his teams to “lean into security and do right by the customer before the company is asked to do so.”
  The areas addressed throughout the discussion ranged to a variety of topics, including how these days security is kept top of mind for engineering leaders during the hiring process. Participants agreed that hiring an AppSec developer is like finding a unicorn. The trick they said is to be more proactive and nurture your own unicorns internally. This can be accomplished by focusing on hiring top security developers and growing them into security roles. The result has significant benefits on all sides. The company will build its AppSec resources and expertise, and employees can value the opportunity to grow and expand their experiences into new areas they may not have known before.
  
  The panelists highlighted that exploring ways to ensure and accelerate approval for security features is a good way to ensure proactive security. One approach is to connect compliance issues that need addressing with security advancements. For example, if the goal to help prevent customer data loss is to add two-factor authentication, one should link a compliance issue that can also be solved by the requested security solution. Decision-makers may look to save budget and pass on simply adding security features, but it will be more difficult to say no to a compliance request. This kind of creative strategic thinking has a way of being a win-win for the company as well as its customers.
  
  The success of AppSec among financial services organizations depends on more than just effective security protocols that secure companies and protect customers. It needs creative, innovative and strategic ideas to enable organizations to have efficient, economical and scalable security. If that sounds like something your organization is seeking, then according to our roundtable panelists our industry has a very bright future.
November 2, 2020
The Role of DevSecOps in Finance App Dev

DevSecOps is critical in developing apps successfully in the rapidly changing and highly regulated finance environment

One of the most important shifts of the past few years in finance and banking was the movement from primarily branch-based banks to mobile-first banks. While these innovative products simplify the end user experience, they also bring up more security concerns, since digital channels expose a number of vulnerabilities. These apps deal with sensitive user data, such as private financial or personal information, which means that the prevention of any type of breach is of utmost importance.

The level of security of a finance app is judged primarily on how well digital transactions and personal data are protected online. Even the smallest security concern can mean that users lose confidence in the app and immediately switch to another provider, often leaving negative reviews in the app stores and damaging the reputation of the company. It does not come as a surprise that the finance industry is one of the most regulated industries in the world: finance apps are required to fulfill the strictest security requirements and offer the latest functionalities at the same time.

Regulatory Concerns in the Finance and Banking Industry

Not only do finance app companies have to comply with traditional finance regulations, but they also are subject to international and local privacy laws. One example is the EU’s General Data Protection Regulation (GDPR), which came into effect in May 2018 and requires companies with ties to the European market to update their data and privacy policies. This affects the finance and banking industry in a number of ways, especially when it comes to getting consent before processing the personal data of users, the right of the clients to request their data to be erased, and additional penalties for data breaches and for failing to comply with such regulations.

Another recent example of changing regulations affecting the finance and banking industry in Europe is the Strong Customer Authentication requirement (SCA), implemented in September 2019. According to this regulation, a secure finance app requires at least two forms of independent authentication elements from its users. These can either be a knowledge element: something only the user knows, such as a password; a possession element: something only the user possesses, such as their smartphone; or an inherence element: something the user is, such as their fingerprint.

Meanwhile, in the United States, the number of potentially applicable regulations make this an even more complex issue. Here, finance app companies might be subjected to a plethora of federal or state licensing or registration requirements and thereby may have to adhere to laws and regulations on both levels, depending on their activity. Providing fintech services in the United States often requires licensing and registration with multiple state regulators including consumer lending, money transmission and virtual currency licenses.

These examples show the additional challenges finance app companies are facing throughout the already challenging mobile development process. Things can be further complicated when developers have to build an app for a global audience with different requirements per country or region. Such companies often have codebases running in multiple different countries; having to manage this complexity while following a variety of regulations can even cause delays in important product releases.

Growing Customer Expectations Require a New Approach

Continuously improving features, maintaining app quality and responding to constantly changing requirements can be a daily challenge for product managers and developers. To tackle these issues, it’s necessary to implement a set of security processes from as early as the planning phase all the way to release—in other words, to create a DevSecOps environment. This can be facilitated by integrating regular information security checks and core security tasks into the software development life cycle to remove previously existing bottlenecks between developers, the security team and the rest of the organization. This approach also helps mitigate risks and allow all contributors to take more ownership and avoid security-related failures.

A DevSecOps environment in the finance or any sector also enables teams to have full control over their stacks and access management and to be able to monitor any and all access within and outside of their environment at all times. Another step forward is shifting the responsibility of security maintenance from the team to a secure and scalable cloud-based CI/CD platform. Automation early on helps developers focus on what matters the most: optimizing their product and developing new features without having to worry about security-related maintenance tasks. It also leaves more time for parts of the process that are essential for safeguarding quality, such as checking code dependencies, threat modeling and detecting flaws before a release.

Building the future’s successful apps in this rapidly changing and heavily regulated space will require adopting an agile, technology-forward mindset and organizational change at the same pace. In the finance industry, it’s especially important to make not only DevOps but also DevSecOps integral parts of the software development life cycle. Only this way can vulnerabilities be minimized across all applications and the different parts of the organization. Fintech, finance and banking apps can only remain competitive if they have solid structural support that enables them to securely connect to—and protect—their users.

September 25, 2020
Security Compass Unveils DevSecOps Platform

Security Compass today launched a DevSecOps platform that guides developers toward building secure applications faster using a set of security analysis tools and processes embedded within it.

Company CEO Rohit Sethi said SD Elements is the first instance of what the company is positioning as a balanced development automation (BDA) platform. By defining a set of best practices for building secure applications, organizations can strike a better balance between building applications fast and ensuring those applications are secure and compliant with any number of regulatory requirements.

Too much of the focus on application development is on pure speed, said Sethi. SD Elements is designed to offer a more structured approach that provides developers with access to threat modeling and risk assessment tools to reduce the number of vulnerabilities finding their way into an application.

SD Elements first gathers details such as the technology stack, deployment environment and compliance requirements. It then classifies risks based on security and compliance policies defined by the organization, which are then employed to surface recommendations to the developer. SD Elements also automatically tracks the status of security activities via integrations with security testing tools such as Veracode, Checkmarx or Fortify to generate reports that identify risks and current mitigation status.

Finally, SD Elements provides access to a library of thousands of security and compliance recommendations and controls, including code samples and test cases, that are mapped to regulatory and compliance standards from all over the world.

To some degree DevSecOps will slow down the rate at which applications are developed. Security Compass, via BDA, is making a case for minimizing the impact security gates will have on the rate at which applications are developed. It’s not clear BDA as a market category will catch on, but as providers of DevOps platforms continue to embed security tools in their platforms the entire category is evolving.

The challenge many organizations face today is they want developers to embrace DevSecOps as part of an effort to shift responsibility for application security to the left. However, organizations are still working to put the tools and processes in place that would enable developers to achieve that goal. Most developers want to build and deploy secure applications; this needs to occur within the context of a structured approach that has a foundation in best DevOps practices.

Each organization will need to determine to what degree they may need to slow down application development to build more secure applications. In theory, the smaller the workloads the easier it is to secure them while continuing to rapidly iterate. However, that level of DevSecOps maturity takes time and effort to achieve.

In the meantime, it’s clear DevSecOps has become a requirement as part of an overall effort to better secure the software supply chain on which so many organizations now depend. The challenge is finding a way to adopt DevSecOps in ways that developers will embrace rather than resist.

August 31, 2020
DevOps and Compliance: A Recipe for Success
In today’s world, DevOps and compliance teams need to work together, not separately

Imagine this: You organized a dinner party weeks ago, promptly forgot about it and just realized tonight’s the night! You have two hours to whip up a gourmet meal for 10 friends. Instead of panicking, you get smart and enlist your kids to form an assembly line. One starts on sides, the other maps out dessert and you begin marinating steaks. All goes well—until the Brussel sprouts burn. Glancing at your watch, you sigh in relief—there’s just enough time to make another batch.

At that moment, your spouse walks in and assesses the situation. The meat is a tad underdone, the veggies could be crispier and the cake is lopsided. You can’t serve this meal! But now your guests are knocking. What do you do?

And more importantly, how does this scenario translate into a genuine business imperative?

The DevOps and Compliance Divide

In many ways, this dinner party dilemma exemplifies the clash between DevOps and compliance teams when it comes to priorities and perspectives.
- The DevOps PoV: Sure, we had a few hiccups along the way, but the end result smells and tastes amazing. Best of all, it’s hot, plated and ready on time for everyone to eat.
- The Compliance PoV: Yes, but the steak is 144°F. It needs to be 145°F to be considered safe. Boiling the veggies instead of steaming them depletes important vitamins from the meal. And both layers of the cake need to be exactly 2 inches tall.
Why the great divide? For starters, their reasons for being are at odds. The DevOps philosophy combines people, processes and tools to empower software developers and speed the delivery of high-quality applications, all while cutting costs. It’s also flexible, iterative and imperfect—experimentation is embraced. Imagine someone saying, “We’ll improve it in the next sprint.”

In contrast, compliance is all about order and uniformity; there aren’t any gray areas. Compliance teams are in place to make sure an organization’s security controls are implemented and monitored consistently. They adhere to a set of rules, mandated by a security framework, government body or customer contractual terms.

Yet in today’s world, these teams need to “cook” together—not separately. And that’s not easy.

Can’t Have One Without the Other

Compliance is a business imperative. Adhering to external regulations and the demands of your customers is of the utmost importance. If you think compliance is extraneous or expensive, try non-compliance. And it’s not just about avoiding millions (or even billions) of dollars in fines. It’s about maintaining trust. According to an IBM study, 53% of consumers say how well businesses protect their data from a cyberattack is “extremely important,” while 64% have opted not to work with a business due to concerns about whether they could keep their data secure. A company’s internal rules and controls are also implemented for good reasons, from instilling accountability to meeting customer requirements. They are not optional.

But neither is DevOps. It’s proven to boost competitive advantage by speeding up software delivery. In fact, high-performing IT teams that implement DevOps practices are more agile, deploying software and changes 46x more frequently with 440x faster lead times than their lower-performing peers. DevOps is also driving digital transformation by streamlining operations, cutting costs, accelerating agility and response, breaking down silos, challenging long-held mindsets, encouraging experimentation and cultivating collaboration, productivity and overall job satisfaction.

2 Cooks in the Kitchen: 5 Steps for Making it Work

So, how can two diametrically opposed “chefs” work in concert to create masterpieces? It’s a question that many CISOs and compliance officers are grappling with …

How do I do my job without standing in the way of DevOps?

To find the answer, they must ask another, broader question …

How do I get complete and continuous visibility of the risks impacting my business?

The only way to do this is to embed automated, transparent risk management into the entire DevOps process. Here’s how to get started:
- Open Up. Compliance and security teams need to be clear about what’s required of DevOps teams. Effective, ongoing communication and granular details will ensure DevOps teams understand their responsibilities and are empowered to do their part. This open line should flow both ways. DevOps teams should be transparent with compliance about their processes, ask lots of questions and understand how their actions will impact the business.
- Get Leadership On Board. Widespread change across people, processes and tools requires support from the top. Executive teams have to believe in it and back it. This will help your organization push through the tough times, convince the cynics and ensure sustained success.
- Make Training a Two-Way Street. Train security teams in DevOps processes—it’s easier to protect what you can understand. And involve security in developer training, from attack “post-mortems” to sharing source code repositories.
- Embed Security from the Start. Most organizations have multiple security scanning tools in place to identify vulnerabilities at different points in the DevOps process. But this often leads to alert overload, security gaps and more questions than answers. Consistent security scanning should be integrated across the software development life cycle and issues should be monitored in a consistent, centralized manner.
- Embrace Automation. This helps organizations understand where vulnerabilities repeat themselves and which ones present the most risk, empowering developers to address real issues quickly so they can get back to business.
Just like perfecting a signature dish, bringing DevOps, security and compliance into alignment takes time. It takes cooperation and patience. All significant organizational shifts do. But by following these steps, you will pave the way for DevSecOps—the holy grail of modern security—to strengthen customer trust and business endurance. Turns out, working together makes things safer and more enjoyable in both the culinary arts and application security.
August 25, 2020
Accurics Adds Compliance Control Support to Code Analyzer

Accurics, at the online KubeCon + CloudNativeCon 2020 conference today, launched an update to its open source Terrascan static code analyzer that adds support for Open Policy Agent (OPA) engine to make it easier for developers to create custom compliance policies in addition to leveraging more than 500 out-of-the-box policies based on the CIS Benchmark.

In addition, Terrascan is now available as a GitHub Action and is included in the popular Super-Linter GitHub Action. It can be installed as a pre-commit hook to help detect issues before code is pushed into a repository as part of a DevOps workflow.

Cesar Rodriguez, head of developer advocacy at Accurics, said the latest version of Terrascan has also been rewritten in the Go programming language to improve overall performance.

Terrascan analyzes the code created to manage infrastructure as code for vulnerabilities as well as indicators of drift. It then creates a threat model for cloud application workloads and, if necessary, will share data with third-party tools to automatically roll back cloud settings to their last known approved state. Once the model is constructed, Accurics monitors the application workload for changes that introduce risks and generates a topology for each workload in real-time to identify any potential indicators of drift.

A recent report based on an analysis of cloud services published by Accurics finds misconfigured cloud storage services are commonplace in a stunning 93% of the cloud deployments analyzed, with most also having at least one network exposure in which a security group was left wide open.

The report also finds hardcoded private keys turned up in 72% of the deployments analyzed. Unprotected credentials stored in container configuration files were found in half of these deployments. A total of 41% of the organizations had high privileges associated with hardcoded keys. In 100% of deployments, an altered routing rule exposed a private subnet containing sensitive resources such as databases to the internet.

Overall, the report suggests that only 6% of cloud configuration issues are being addressed using manual remediation processes.

Ideally, developers should be implementing cybersecurity and compliance controls as they deploy applications in the cloud. The challenge is that while developers have ready access to tools to automate the configuration of those services, not many of them have tools to verify whether those services have been implemented properly.

IT organizations will still need to scan for vulnerabilities in runtime environments. However, tools such as Terrascan will enable IT teams to advance the adoption of best DevSecOps practices by providing developers with access to scanning tools that can be incorporated easily with a continuous integration (CI) workflow.

Of course, the biggest DevSecOps issue remains culture. However, most developers don’t intentionally want to deploy insecure cloud applications. If given access to the right tools, most developers will do the right thing as long as it feels like a natural extension of an existing workflow rather than an unnatural act that was defined by a cybersecurity team that has little to no idea how applications are actually constructed.

August 17, 2020
How To Build a Business Data Map

Recently on devopsy.kinsta.cloud, Anais Baig provided a brief overview of the privacy process and capabilities that developers need to think about to comply with new global privacy laws such as Europe’s GDPR and California’s CCPA. Top of the list for complying with these laws? The need to build a business data map.

It’s no exaggeration to say that without a comprehensive, accurate data map—or, in other words, a complete inventory of the personal data the business possesses at any given time—it’s impossible to comply with these modern privacy regulations. Developers will understand better than most the difficulty in creating and then maintaining this record.

But it can be done, and today we’re going to dive into the requirements and some of the technical processes that go into crafting a data map.

What’s in a Data Map?

In simple terms, a data map shows the personally identifiable information (PII) your business possesses, why you possess it, where it lives and how it’s being used. To answer these four questions, you’ll need to audit the databases in your business. Be sure to include those that are part of third-party SaaS applications as well as your own proprietary data systems; figure out the fields of information contained in each. Then you’ll need to coordinate with your team to understand the business purpose for which each of those data points is being used.

The bulk of the work that developers typically do is that first step: auditing the business data system and documenting the database structures. At the very least, these are the things that you’ll need to be able to say about every field of personal information you possess:

Source: How was it collected?

Use Case: What is the business purpose for which it is being used?

Storage: Where is it being stored for additional processing, transformation or record-keeping?

Access: What business units have access to the data?

Retention: What is the schedule for deleting this data or renewing the user’s consent to possess it?

Consent: Was this data obtained through explicit customer consent?

If you’re a small business, sometimes a data map can be “visualized” with a simple spreadsheet, but it very quickly uses its utility as data infrastructure scales. Larger businesses often find it very useful to construct a data map like an actual map, with a visual representation of the data relationships that exist in the business. In this form, a data map most often contains nodes and links to show how different systems that contain any personally identifiable information link together in your organization.

Here’s one built by Ethyca:

As you can imagine, without automated tools it takes a good bit of grunt work to get to this point of elegant visualization. For those just getting started mapping data in their business, we recommend a hybrid mapping approach.

The Hybrid Approach to Mapping

The hybrid approach means using an automated baseline process to identify and record the individual personally identifiable information that your organization is processing into one central repository, and then using manual label analysis data analysis to annotate and verify entity relationships across applications in your stack.

Label analysis involves using a data attribute’s name to decide which data dictionary element the attribute identifies. For example, an attribute named ‘email_id’ can be identified as ‘person.contact.email-address’.

When the attribute’s name alone is not enough, the name of the entity to which the attribute belongs is included in the analysis. For example, the attribute named ‘name’ in an entity named ‘customer’ can be identified as a name of a person, whereas a similarly named attribute in an entity named ‘city_master’ can be identified as a name of a city.

Sometimes a group of attributes occurring together can be identified easily. For example, attributes with names ‘lat’ and ‘lng’ can be identified as latitude and longitude of a location. Similarly, attributes with names ‘f_name’ and ‘l_name’ can be identified as parts of a person’s name.

Data analysis lets you manually confirm the relationships posited in your label analysis by using actual data from your databases to test.

The presence of certain values or patterns in the actual data can confirm certain mappings. For example, if the data for an attribute follows ‘foo@bar.com’ pattern, it can be confirmed that this attribute captures an email address.

Range values captured in attributes of different tables can be checked to see if those attributes are referring to the same piece of information, such as a user_id, that can be used for linking the tables with specific relationships. Similarly, the absence of values in an attribute can confirm the opposite.

If you’re not using an off-the-shelf data mapping solution, the label and data analysis processes can be arduous. But if done correctly, by the time you’ve completed the exercise, you’ll have a comprehensive understanding of how the data in your business links together, and you’ll be ready to start answering the compliance-related questions about each PII field you hold. You can also begin thinking about processes for maintaining the map’s accuracy as your data inventory flexes and evolves.

August 17, 2020
Functional Safety in Embedded Design Starts with Code Development

With embedded software likely to become more complex, now is the time to start thinking about functional safety

As the world has become increasingly more dependent on embedded systems in functional safety markets—such as rail, automotive, aerospace and medical—ensuring the safety of the software in those systems has become even more imperative. That assurance must begin with software development.

As we all know, software development is the point at which many vulnerabilities are introduced, potentially leading to future performance, security and safety issues. The challenge for many embedded software developers is that they are often dealing with highly complex environments. In general, these complex environments are built using C and C++ programming languages.

While C and C++ provide developers with the flexibility and scope for the innovation that embedded environments demand, they also introduce risk. Code can have undefined or unspecified behavior, or may not behave the same way when run on different hardware. Even the most skilled developer may make decisions that inadvertently lead to errors.

Embedded Systems and Functional Safety: Cultural Appreciation

There are ways to reduce software development risks. From a cultural perspective, safety and security need to be baked into the software development process, right from the very start and continuing throughout the entire DevOps life cycle. Of course, this is a practice that should be happening across all software markets, not just within embedded design.

At the same time, there needs to be a greater focus on enforcing compliance with functional safety standards. This practice requires strategies to ensure the safety and security of systems. In some industries, such as rail and automotive, the use of these standards is mandated as part of approval and compliance processes.

Functional Safety Standards

Functional safety standards require performing a hazard analysis and risk assessment of the system. Based on the results, safety functions are then implemented to reduce the risk to an acceptable level. Functional safety standards set out appropriate software development and verification actions to mitigate known risks.

Some of the main functional safety standards in use today include IEC 61508, which covers electrical, electronic and programmable electronic safety systems. First published more than 20 years ago, IEC 61508 is also the basis for several other functional safety standards including ISO 26262 for automotive, EN 50128 for rail, IEC 62304 for medical devices and ISO 25119 for agricultural machinery.

Similar to other standards, functional safety standards do not always receive a warm reception because there is a perception that they require additional work and cost. In fact, by requiring consistent, high-quality coding practices, functional safety standards can reduce time-to-market and cost because they introduce best practice efficiencies into the development process.

Coding Standards

Most functional safety standards require or recommend the use of coding guidelines. For example, in the automotive industry, ISO 26262 mandates the use of coding guidelines and highlights specific areas that must be covered, such as the use of a safe language subset and naming conventions.

Typically, a coding standard is made up of the collective knowledge of many people and organizations, such as manufacturers, consultants and industry associations. This collective knowledge is then used to provide developers with a set of rules to ensure that the code they are developing is safe, secure and compliant. Coding standards also engender better quality coding practices by making code more consistent, readable and understandable within a team.

Depending on the project, organizations often choose to implement an external coding standard either fully or partially. They may also decide to create their own in-house coding standard based on an external standard or their own experience.

While MISRA C and MISRA C++ were originally created for the automotive industry, the coding standards are now widely used across multiple industries. AUTOSAR C++14 Coding Guidelines were developed to address the requirements of modern C++ development environments, including autonomous vehicles and in the future will be used as the basis of a new MISRA C++ standard.

Another popular coding standard used across multiple markets is CERT (coordinated by the CERT division of the Software Institute at Carnegie Mellon University), which focuses on security. With increasing awareness of cybersecurity risks, the use of CERT in embedded software development is likely to increase.

Successful Implementation

Regardless of the approach, successful implementation of coding standards depends on several factors. As there may be resistance to the implementation, teams need to be involved in the selection process of a coding standard and supporting tools. By being included in the decision process, it helps the team to understand why the requirement is critical.

In addition, while it is possible to carry out manual code reviews against a coding standard, any project of significant size will need an automated static code analysis tool.

Static code analysis tools can detect thousands of defects quickly and accurately, which frees up the developers to consider the implementation of the design. These tools work by both analyzing an individual developer’s code changes before they are committed and then scanning throughout the entire project as part of continuous integration (CI). For that reason, static code analyzers harmonize well within DevOps-led development environments.

With embedded software likely to become more complex—especially against a backdrop of AI, ML and IoT—now is a good time to start thinking about putting in place an effective functional safety strategy, which includes tools such as static code analyzers and coding guidelines.

August 13, 2020
A Developer’s Guide to CCPA, GDPR Compliance
Here’s what developers need to know to ensure compliance with the two biggest privacy laws

The digital landscape is continuously evolving, and privacy regulations such as CCPA (California Consumer Privacy Act) and the European Union’s GDPR (General Data Protection Regulation) are in effect to give consumers their fundamental right to data privacy.

These regulations force organizations to revamp their operations to comply. This means all departments within an organization, from marketing to software development and everything in between, have to keep privacy regulations in mind and tweak their workflows accordingly.

In this article, we will discuss the steps developers can take to stay compliant with these regulations.

Understanding Data Rights

With more people concerned about their data rights, giving them complete control over their data is essential in today’s world. Under both GDPR and CCPA, here are all the rights consumers have concerning their data:
- The right to be informed.
- The right of access.
- The right to rectification.
- The right to erasure.
- The right to restrict processing.
- The right to data portability.
- The right to object to processing.
- The rights concerning automated decision-making and profiling.
A consumer can practice these rights at any given time and enterprises are obligated to fulfill these requests as soon as possible.

GDPR and CCPA recognize that more and more consumer data is available online, which increases the possibility of cyberthreats and invites other malicious activities. This is why it’s crucial for these regulations to protect the consumers’ data while dissuading any instances of data breach or sprawl.

The Risks for Non-Compliant Businesses

The European Union (EU) has a history of making an example out of companies that are non-compliant with its regulations. One of the EU’s most recent actions was against Google.

France accused Google of infringement regarding the essential principles of the GDPR: transparency, information and consent. “Enforcement action was geared toward the way Google obtained consent,” said Myriah Jaworski, an attorney at Beckage PLLC.

Google did not present how and why an individual’s data was collected and stored, nor did the company make it easily accessible. Google was fined $57 million by the EU.

Seeing that even an industry giant is not immune to prosecution, it is clear that no company can get away with GDPR or CDPR non-compliance. To stay safe, developers must be well-versed in all the regulations and build their websites, apps and software with compliance in mind.

CCPA vs. GDPR: What’s the Difference?

While both laws serve to protect the rights of the individual, there are some differences between the two regulations. The following are the significant differences between the two laws.

Who Needs to Comply

The GDPR has a broad scope concerning who has to stay compliant with the law. It covers all citizens of the EU and regulates all organizations that collect and store personal information of EU citizens irrespective of their location and size.

In contrast, the CCPA places constraints on the size of organizations that need to comply. It applies to organizations that have $25 million or more in annual revenue; possess the personal data of more than 50,000 “consumers, households, or devices”; or earn more than half of its yearly income selling consumers’ data.

Financial Penalties

The GDPR mandates penalties based on non-compliance and data breaches. These penalties can reach up to 4% of the company’s annual global revenues, or €20 million (whichever amount is higher), with the commitment that administrative levies will be applied proportionately. CCPA fines are not cumulative but instead are applied per violation, which can reach up to $2,500 per unintentional violation and $7,500 per intentional violation, with no upper cap.

Consumer Rights

Both regulations give the consumer specific rights that they can exercise. Some of these rights include the right to have information deleted or accessed. The GDPR specifically focuses on all the data related to European Union consumers, whereas the CCPA considers both consumers and households as identifiable entities. Businesses need to test their processes and ensure they can accommodate these rights.

Use of Encryption

The clauses on encryption in both laws constitute an area that, although similar, still have some differences. Both laws call for access to data encryption, making this an essential part of the privacy protection component for businesses.

Steps to Compliance

Developers are the front-line infantry in this struggle toward compliance because websites and mobile apps are the first interactions a consumer will have with an organization. It is essential to cover all bases from the start to make the compliance workflow as smooth and efficient as possible. Let’s take a look at the steps developers can take to comply with each regulation.

Complying With CCPA

Data Mapping

To stay compliant, developers need to integrate proper data-mapping techniques into their systems. The law dictates that organizations should be fully aware of all the data they collect—this refers to what is collected, where it is stored and how it flows through the organization. Some operational suggestions include designating a single source of truth, maintaining lineage and tracking all data within the organization.

Inform Consumers

To comply with the CCPA, organizations will need the capability to fulfill data subject access requests (DSAR). A company’s website must show the consumer what data it is going to collect and how it will be collected. Developers can work with privacy officers to create a standard privacy notice for the website or an abbreviated pop-up policy at the point the data is collected.

Verify Queries

Organizations will be met with a flurry of requests from consumers exercising their rights under these regulations. Developers need to create a system by which the consumer can be authenticated and the correct information can be given to them. To streamline this process, developers can create a dedicated email account for requests and design workflows for verification purposes.

Data Minimization and Purpose Limiting

When collecting data, organizations need to make sure that the data is only used where necessary. To ensure that, developers can create forms that only require minimum information (data minimization) and organizations can make sure that internally used data is in line with privacy policies (purpose limitation).

Data Security

Under the CCPA, organizations are required to protect the data an organization keeps about a specific individual. Although not explicitly mentioned, it is beneficial for organizations to encrypt data at rest to prevent further compromise after any data breaches.

Developers can ensure security by implementing robust applications that offer end-to-end encryption to protect consumers’ data.

Complying with GDPR

Efficiently Store Data

The way an organization stores data can be the difference between compliance and non-compliance under GDPR. Developers need to ensure that minimal data is being derived from consumers to reduce liability and only store the data that is necessary for their processes. Lastly, developers should implement data subject access rights (DSAR) tools in their storage to efficiently respond to subject data access requests.

Subject Access Requests

Developers need to integrate a system that can map all the data in the data stores and make them easily accessible when consumers request access to the data that the company keeps, even complete deletion.

Contacting Users

Under the GDPR, an organization can not assume consent; it must be asked for. Developers working on a feature that will trigger an email or another message to be sent to users will need to integrate it with their organization’s consent tooling and check if they already have a consent channel for their use case. This will likely take the form of some source-of-truth database and an API that developers can query before sending messages.

Profiling

Profiling is the use of data to personalize a customer’s experience. To be compliant with GDPR, organizations should have a clear way for users to opt-out of profiling. The only important thing for developers going forward is understanding what counts as profiling and respecting a users’ choice before implementing any form of personalization.

Rewrite your Privacy Policy

The GDPR has brought several amendments to the current structure of any organization. The IT group is essential for organizations to revamp their privacy policies according to the GDPR. In this case, developers can integrate the privacy policy into company websites or as a pop-up to comply with the GDPR right to notice.

Key Takeaway

CCPA and GDPR are revolutionizing the data privacy sector, and organizations must comply with these regulations. Developers and marketers alike are going to have to find new ways in which they can efficiently comply with these regulations without hindering their current performance. Developers need to integrate automation to create a streamlined approach to compliance throughout the organization.
July 29, 2020
3 Reasons Why Traceability Should Be a DevOps Priority

Traceability in DevOps is about ensuring clarity, accountability and the best possible end product for customers

There’s a lot to think about when it comes to mobile DevOps. For a start, there’s the need for effective cooperation between members of different teams, perhaps even via team collaboration software for remote workers. With so many people working on DevOps, it’s easy for some to become siloed from their colleagues, hampering communication and undermining teamwork.

Then there’s the wider question of DevOps strategy—deciding on a vision, setting goals and working out how to measure your success (or otherwise, as the case may be). One thing that has to be central to your strategy is traceability. You may have come across the term a few times before. It’s commonly used elsewhere in the business world, especially with regard to supply chains. Basically, what it means is keeping track of a commodity or product at every stage of the production process.

Records of the product’s entire manufacturing and distribution history are kept so that the sources of any problems can later be determined and dealt with. Traceability thereby ensures that suppliers can act quickly and decisively in the event of a product recall, for example.

Another advantage of traceability is that it provides additional transparency, which helps to maintain consumer confidence. As consumers are becoming increasingly aware of how products are sourced and manufactured, this is now an important consideration. It reassures consumers that manufacturers and suppliers are aware of their concerns and that they’re looking out for their best interests.

You can see already, then, how much of this also applies to mobile DevOps. Traceability in DevOps is about ensuring clarity, accountability and the best possible end product for the consumer. But it’s especially important in DevOps because speed is of the essence—there’s constant pressure to get apps developed, into the hands of users and then incorporate feedback as soon as possible. It goes without saying that this can lead to oversights and slip-ups that might otherwise be avoided.

In addition, DevOps teams have sought to accelerate this process by allowing for greater decentralization and autonomy among their teams. The logic behind this is that it allows for quicker delivery and deployment. Screenshare solutions and other such technological fixes can help to facilitate closer collaboration. However, this easing of control can nevertheless create some potential for confusion in the development process. That may make it more difficult to maintain consistent coordination between developers and testers, and so on.

Here we’ll list three of the key reasons why traceability should be a leading DevOps priority. All are based on the experiences of development teams and the challenges they’ve encountered.

Cutting Down on Defects

As we’ve already discussed, the pressures for faster software rollout and feedback can make it more likely for certain bugs to not be addressed as quickly or as effectively as might otherwise be the case. We’ve noted further that buggy apps can do a lot of damage to companies’ reputations by providing a shoddy and unreliable user experience.

This can have serious repercussions—after all, word travels fast, especially on social media. It’s therefore in your interests to take whatever steps you can to make sure your software runs as smoothly and reliably as possible.

Experience strongly suggests that the more rigorous your traceability processes are, the less prone to faults your apps will be. The completeness of your captured traceability information makes all the difference here.

So, for example, EMR software developers will get great value out of more complete traceability info, as it will contribute to reducing the likely defect rate. This correlation between detailed traceability and defect rate can help to produce more reliable apps and improve efficiency by cutting out avoidable errors and bugs. You should actively solicit feedback from users where appropriate, and integrate this into your wider customer support package.

Ensuring Compliance

In other industries, thorough traceability is often a requirement set by regulatory bodies. This can be so that, in the event of a product needing to be recalled, the entire supply chain can be re-examined and the cause of the problem discovered. For example, food and feed businesses operating in the EU have been subject to compulsory traceability requirements since the General Food Law came into force in 2002. Similarly in DevOps, developers have to take regulatory compliance into account.

Thus, robust and detailed traceability helps DevOps firms working across a variety of sectors in their efforts to comply. There are numerous industries where this is relevant, whether it be financial services (a well-known regulatory minefield), HR software, insurance or public sector contractors and healthcare firms, any of which may be subject to stringent traceability requirements.

Tracing code is a common prerequisite insisted upon as part of compliance frameworks. For example, you won’t be able to complete the SOC 2 process integrity requirement unless you’re able to provide a complete, evidenced account for each code alteration in your application’s source code.

Improving Speed Without Sacrificing Quality

We’ve already discussed how there’s a delicate balancing act that needs to be struck in DevOps. That’s the balance between software rollout speed and the reliability of its performance. We’ve also noted how the increasing autonomy of different sections can hamper coordination between them; thus providing some benefits in terms of speed and rollout but often at the cost of the reliability and quality of the end product. The key here, then, is to find a way of threading the needle, ensuring that apps can be produced at a consistently quick rate while maintaining rigorous standards.

This is where traceability comes in. It helps to not just enhance speed but also drive up standards. It allows developers to execute tasks more quickly while simultaneously improving the standard to which they do so.

This also has a positive effect on overall efficiency levels, freeing up resources (i.e. members of the team) to take on other tasks for which they might be needed. Engineers working on contact center software, for instance, can benefit from better-maintained code by reusing or altering existing code depending on their needs.

It’s worth noting again here that requirement-to-code traceability may be mandatory from a regulatory standpoint. It will depend on the industry in which you’re working. But even if it isn’t, it’s something that’s still worth doing. It can lead to dramatic improvements across the board, leaving as its legacy sharpened and more efficient processes that enhance your team performance, benefits clients and consumers, and—most importantly—deliver real gains for your bottom line.

Having taken all this into consideration, then, you’ll need to think about exactly how to implement DevOps traceability. Certainly, when introducing traceability processes, you must do so with real care and consideration. Being too rash about implementation can either create bottlenecks, thus exacerbating or even causing problems which traceability otherwise ought to help resolve, and slowing down the overall speed of production.

Make sure, then, that traceability is implemented in a way that takes the needs of developers seriously. To start with, draw up a guideline document offering developers a clear and concise explanation of what’s expected of them. Outline the traceability process and how it ties in with key objectives. Furthermore, give developers some autonomy in the choice of tools they use for traceability purposes. You might, for instance, make astute use of automation (such as automatic code checks, for example). This should help everyone reap the rewards of traceability and avoid any unnecessary implementation hiccups.

June 25, 2020