Using AI for customer service in your company is a definite method to save time and money. If you’re like most business owners, you’re constantly searching for fresh, creative ways to improve your enterprise. We’re here to inform you that improving AI customer service is a simple and rapid win.
If you have a team of software engineers and want to move them to Mac, you will need to consider a number of things before you do so.
As we are about to see an industry-wide redoubling of efforts on secure software development, this is a good time to point you in the direction of essential resources offered by the National Institute of Standards and Technology. Beyond recent cyberattacks and more remote work, it’s anticipated that the Payment Card Industry Security Standards Council will release PCI DSS v4.0 in Q1 of 2022. It is likely to increase standards for virtually all eCommerce software. Like reusing good code, it’s not always necessary to reinvent the wheel. Most organizations will be playing catch up with NIST’s frameworks. Those wanting more can add to it.
No one in their right mind is going to tell you that secure software development is easy. It requires extra effort. You’re competing with what probably amounts to a lot of amateur hackers, but also groups of dedicated Black Hat professionals. Some of them are backed by corrupt states – the usual suspects. They stand to profit if they can penetrate your systems. Conversely, it’s hard to think of a case where anyone really increased their profitability with secure software.
Leastwise, we can start with the top-level benefits of keeping your software secure:
Of course, that all sounds nice. It’s really quite debatable whether any of these reasons will inspire your C-levels to make a serious commitment to securing your software. As of 2020, according to Verizon, only 27.9% of companies were fully compliant with the current PCI standards. These companies recognize one other benefit associated with secure software development:
In a world where companies cease striving “to not be evil” – it’s always good to put a dollar figure to everything. Feel free to convert to Euros, Sterling, Francs, and seashells, if you like.
Let’s take a quick look at some of those fines and penalties.
Violations of the EU’s General Data Protection Regulation (GDPR) can result in fines of up to €20 million or 4% of annual global revenue, whichever is highest. Two examples of many – Google incurred €50 million in fines; Marriot €20.4 million.
In 2020, Premera Blue Cross was fined $6.85 million by HIPAA for a data breach involving the records of 10,466,692 individuals.
The Payment Card Industry can impose fines on non-PCI compliant merchants of up to $500,000 per incident for security breaches. Costs of notifying customers of breaches plus costs of recovery can push costs much higher though. It cost Equifax at least $575 million, and Target at least $292 million.
Then there’s the ransomware attacks – where CNA Financial paid $40 million. It makes all of the attention on Colonial’s $4.4 million payout seem trivial, if not for making national news and forcing responses in Whitehouse press conferences… and threatening gas supplies to entirety of the US eastern seaboard.
Though dated (2004), NIST’s Engineering Principles for Information Technology Security remains equally true today, the principles haven’t changed. Below, all 33 principles of secure software development are listed verbatim, deserving all of the attention they can get. One is to wonder, if all of these principles were followed how many critical cyberattacks could have been prevented?
Security Foundation:
Risk-Based Principles:
Ease of Use
12. Where possible, base security on open standards for portability and interoperability.
13. Use common language in developing security requirements.
14. Design security to allow for regular adoption of new technology, including a secure and logical technology upgrade process.
15. Strive for operational ease of use.
Increase Resilience
Reduce Vulnerabilities
Design with Network in Mind
Highly recommended download: Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF) by Donna Dodson, Murugiah Souppaya, and Karen Scarfone, was updated in April of 2020. Complimenting the principles, this framework details secure software practices and tasks to prepare your organization, protect and produce well-secured software, and for responding to vulnerabilities. It provides examples and a list of references for each task.
Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality (PW.4):
Lower the costs of software development, expedite software development, and decrease the likelihood of introducing additional security vulnerabilities into the software. These are particularly true for software that implements security functionality, such as cyptographic modules and protocols.
PW.4.1:
Acquire well-secured components (e.g., software libraries, modules, middleware, frameworks) from third parties for use by the organization’s software.
BSA: SM.2, SM.2.1
IDASOAR: Fact Sheet 19
MSSDL: Practice 6
SAMM15: SA1-A
SCTPC: 3.2.1
SP80053: SA-12
SP800181: K0039
In our previous article about President Biden’s Executive Order on CyberSecurity (and with NIST, generally), we talked Software Bill of Materials, Tracking Vulnerabilites and Patches. The documents and principles are a comprehensive source of secure software development best practices. Like initially noted, it’s not necessary to reinvent the wheel. We can add to the wheels, and so there are a few SSD best practices deserving of extra notes.
Only provide people, user accounts, and the software itself, the privileges (or access) to what they need to do their jobs, roles, and functions. It can apply to every level in a system from the OS to the network, databases, and applications. This can also extend to the physical environment, for example only letting authorized personnel in the SNOC or only if they are accompanied by a supervisor. Employees are actually responsible for an estimated 40% of data theft – and typically when they are about to change jobs.
So, one area of risk is not actively managing PoLP and removing permissions if an employee’s role changes or even when they do leave the company. Somewhat related is that while many companies rightfully insist on nondisclosure agreements (NDAs), far too many fail to “secure” (hardware, software, hard copy) materials provided to team members on their departure. Google Docs is one system rife with people continuing to have access to files… forever.
In addition to frequent testing, use a linter or a static code analysis tool to help catch defects before creating pull requests. Linters and static analysis can detect memory leaks, array or string overruns, access violations, etc. A linter can also help enforce style guide rules, make code easier for everyone on the project to read, and keep code reviews on task.
Oops, made a mistake – will keep it there, but it’d take one second to delete that erroneous “ly.” It’s fast, easy, and there’s no real cost when developers fix errors while they’re writing code. Testing code as it’s written also makes debugging fast and efficient because developers have the code fresh in mind. After this point, however, the cost of finding and fixing defects begins to quickly increase.
Penetration tests or pen tests are simulated cyberattacks against your system to find vulnerabilities. Several regulations (GDPR, HIPAA, SOX, the PCI DSS, and others) require directly reference periodic risk assessments and/or penetration tests. It’s generally understood that a risk assessment includes a penetration test. Again, all eCommerce software is likely to be impacted by PCI DSS v4.0 which is expected to be released in Q1 of 2022.
In most cases, regulations have required that a pen test or risk assessment yearly and/or following any significant changes to the system. Gradually, more organizations are conducting penetration tests more frequently. A wide range of software penetration tools are available. However, more and more companies are making use of bug bounty organizations like BugCrowd and HackerOne, or creating their own programs like Microsoft, Facebook, and Intel.
As defined by Biden’s Executive Order, we can expect to be required to share a lot more data should our systems get hacked. Checkout Section 2 of EO 14028. I’d draw attention to:
(c) The recommended contract language and requirements described in subsection (b) of this section shall be designed to ensure that:
(i) service providers collect and preserve data, information, and reporting relevant to cybersecurity event prevention, detection, response, and investigation on all information systems over which they have control, including systems operated on behalf of agencies, consistent with agencies’ requirements;
That is worthy of a post unto itself, suffice that the actual requirements of the EO will trickle out through May of 2022. It’s likely that we’ll cover more on secure software development over the coming year, and where possible and appropriate, we’ll include news about the “latest paperwork.” In the meantime, we can be thankful that NIST won’t be using nude body scanners to ensure software developers aren’t a security risk.
Gitential makes it easy for you to automatically track critical performance metrics with four levels of visibility – company level, by project, team, or individual. You’ll have on-demand access to comprehensive statistics across the four main drivers of software development – productivity, efficiency, quality, and teamwork. With this data, you can begin measuring the benefits of teamwork in software development, identify what’s holding your team back, improve cycle time, and more.
