Blog

As if the sequester isn’t causing enough problems for the Federal Government, we are now learning that a vast majority of Federal cybersecurity employees are over the age of 40, and most of those are even closer to retirement than the threshold. The 2012 Information Technology Workforce Assessment for Cybersecurity report was released last week and with it comes some fairly stunning revelations.

• 5% of the Federal Cyber workforce is 30 or younger
• Close to 50% of the group is within 10 years of retirement
• 33% is within 3 years of retirement

The broad message here is that there will be an enormous gap to fill once these people start to retire. Not only will we be losing the seasoned front line soldiers that defend our networks, systems, financial well-being and personal information, but we will also be losing all of the institutional knowledge that is locked away in their brains – often used but rarely documented. So much of what cybersecurity professionals do is based on good habits, repetition, and deep, intimate knowledge of the systems and software that they have nurtured for the past 20 years.

So how do we pass along this institutional knowledge and years of experience to the freshly minted CISSP? Before all of this knowledge flows out the revolving door, the Federal Government must implement a process that allows them to capture the infinite knowledge that the cyber workforce has amassed, and implement it in such a way that allows them to ensure that the next generation of cybersecurity professionals implement the standards, best practices and policies that have been in use for the generations past.

Just found a great blog post by Kenneth van Wyk in Computerworld, where he draws an extended analogy between personal health and secure software.  As van Wyck points out, achieving both requires hard work, specific goals, a plan to get there and the discipline to stay on track. We agree — the benefits are worth it in both cases.

In fact, we think the same analogy applies to overall software health – meaning not only improving security weaknesses, but the fragile/buggy code throughout an app, both custom and open source.

So if personal health is about eating right, increasing exercise and minimizing bad habits, software health is about following proven polices and methodologies for code creation, validation and verification.  Eating right for your app means “growing,” choosing and ingesting only the code and artifacts known to be “good for you” (with libraries like the CWE playing the role of the FDA in this scenario). And just like strenuous exercise, testing your code can hurt sometimes, but it always makes for a stronger app.

Your New Year’s resolutions may have long since lapsed, but we know the just the personal trainer to get your software into shape!

Just found nice blog post worth reading on the high cost of poor software quality from Wireharbor Security, a consultancy in the Midwest.  We’ve already covered a lot of the company’s points — that software glitches can cause serious harm to an organization’s brand and bottom line, for example – here in our own blog, on our Twitter page and of course in our CEO’s book, “Glitch.”

But they also added a couple worth noting.  Such as the negative impact on business valuation that can be attributed to fragile software and the implied costs associated with fixing it post-M&A.

And the loss of business agility that results from an inability or reluctance to upgrade existing software applications out of fear they will become unstable (again).  This latter problem being a very serious one for large businesses, which “get stuck with a lot of antiquated and cumbersome technology at a time when they face serious challenges from startup companies that threaten their market position with new, disruptive technology.”

Healthy software means a healthy business.  It’s not sufficient, but certainly necessary.

Just read a very thoughtful blog post by Anders Dinsen on software testing that expands on a recent lecture by the essayist and scholar Nassim Nicholas Taleb, whose work focuses on the problems of randomness, probability and uncertainty.  Taleb gave the lecture in support of his new book, “Antifragile: How to live in a world we don’t understand.”

According to Dinsen, Taleb made several points in his lecture that are directly relevant to software testing, starting with the assertion that “technology is inherently fragile.”  We can argue over why that statement is as true today as it was decades ago – a lack of rigorous governance, an artisanal approach to development, the emphasis on delivery over quality – but not its essential truth.

Dinsen says this is the opportunity for “anti-fragile software projects,” which use great testers (and we would add “great automated testing solutions”) to find as many small defects as possible before production, and learn from these problems to avoid them in the future — and deliver stronger software.

To tie this back to Taleb, this should also lessen the occurrence of “black swans,” the metaphor he used to describe events that are a surprise to the observer, have major effects and are often inappropriately rationalized with the benefit of hindsight.

A few less technology black swans would be a good thing.

Great blog post here from software testing guru Jonathan Kohl with a look at the surprising number of consultants and trainers using board games, role playing games and even magic tricks to teach the concepts and principles of proper software testing.  Timely subject for this holiday gift-giving season!

Interesting entry on John Dodge’s excellent Enterprise CIO Forum site that echoes and expands on our last blog post “Pinto software development in a Fusion hybrid world” – making many of the same points regarding IT with very similar, even identical, language.

In his post, “How IT leaders can improve compliance and control,” HP’s Keith Macbeath makes a compelling argument that today’s IT is still a “cottage industry,” built on “artisanal” and handmade processes, and only by moving to automated, standardized processes can we control the resulting work product and achieve compliance – the demand for which he says is growing every day.

We couldn’t agree more.

In the 2012 quality rankings for cars just issued by Consumer Reports, Ford, took a major hit – falling to the bottom of the list.  Once  Consumer Reports’ most reliable domestic automaker, Ford must have angered buyers with a bad batch of engines or faulty brakes, right?  Some mechanical design or manufacturing disaster.

Nope.  A big part of the drop was attributed to glitches in their MyFord infotainment and Sync communications software.

This is worth noting for two reasons.  Obviously, it’s another proof point that software is everywhere.  Today’s cars are like computers on wheels, and getting smarter than your PC or your smartphone. (Tip of the hat to old friend Joe McEndrick for pointing to us to this tidbit.)

But it’s also part of a larger story.  In historical terms, the mechanical systems in today’s cars offer amazing reliability and efficiency.  The average 2013 sedan offers muscle-car power with econobox fuel efficiency, can go 100,000 miles between tune-ups, and last 200,000 miles or more if maintained properly.  One big reason for this quality improvement is that the processes and tools used to design, test and make cars today are digital, automated and follow proven best practices.  The vast majority of potential weaknesses, flaws and faults in mechanical parts and systems are exposed and corrected during digital design and testing, before the physical product is delivered to the customer.

As Ford’s problems illustrate, the software in today’s cars (and just about everywhere else), however, is built in a manner far closer to the bad old days of U.S. car manufacturing, when design was individual and artisanal, and companies let buyers do their testing in the field, then fixed what broke in subsequent years or models.  In the ‘60s and ‘70s, many U.S. car buyers would avoid first-year models to give the manufacturer a chance to work out the kinks (or even avoid fiery rear-end collisions, in the case of the Pinto).

Raise your hand if you’ve ever delayed the purchase of a new or upgraded software package until a subsequent point-release so you could avoid dealing with the inevitable “bugs” — or wished you had.

So just as the Deming/Six-Sigma quality movement fueled the rise of the Japanese auto industry, ultimately saved the U.S. auto industry, and gave us today’s dependable and economical cars – it’s time for a software quality revolution, one focused on best practices, automation, testing and governance.

The stakes are far higher than being stranded at the side of the road because a mechanical part on your car failed due to poor design.  Software is at the heart of every aspect of our critical infrastructure – and its too-common record of failure will continue to have catastrophic results for our national security, financial stability and even personal well-being until we move software design and testing into the 21^st century.

Software problems continue to plague United Airlines, as the integration of reservations systems from their merger with Continental failed again yesterday, stranding hundreds of customers.  Timing couldn’t be worse — at the start of the busiest travel season of the year.

Previous glitches had already resulted in a negative impact on the company’s financial results, but the company’s CEO had publicly assured Wall Street that the problems were fixed.  So now it’s a credibility issue.  United runs the risk of acquiring a reputation with customers as an unreliable vendor, with Wall Street as questionable management team.

It’s a familiar story, but it doesn’t have to be this way.  Whether you’re building new mobile apps, modernizing legacy software or rationalizing your application portfolio – WebLayers’ automated software testing solutions incorporate industry standards and proven best practices to help you deliver quality software — the first time.

Click on the following link to view a brief presentation and learn more.

We all know security is a difficult challenge for software development, but how and when you deal with it can have a dramatic impact on your organization’s bottom line and reputation.

In a recent study by the Ponemon Institute, the average cost of a security breach was estimated to be more than $7 million, and the most frequent cause of these breaches, at more than 40%, was human error during the development and maintenance of applications.

WebLayers’ experience with a wide range of enterprise, government and defense customers has shown that you can minimize your risk and improve the quality of your software by following five proven best practices for secure software development:

1. Use standards and encourage their use – Provide your development teams with testing tools that leverage proven standards (DISA/STIG, NIST/FISMA, CWE) for common vulnerabilities, such as DoS, injections and inclusions, input validation, object construction, etc., and help your teams understand how and why they need to use these tools.
2. Verify all work, from insiders, contractors and outsourcers – With deadline pressures and the increased use of Agile development methodologies, the temptation to “cut and paste” prior, untested code can introduce dangerous vulnerabilities.
3. Don’t rely on security checks being done elsewhere – It’s your reputation and brand on the line, so make sure you “own” the security testing process.
4. Don’t leave security problems to operations staff – Testing before your application reaches a production environment will ultimately save time and money, and improve quality.
5. Check early and often – Delivering quality software requires testing throughout the SDLC, performed by teams given the guidance and understanding required to embrace this approach.

It all comes down to prevention vs. remediation. Early detection vs. after-the-fact treatment.

It’s kind of like the old Fram Oil Filter commercials – where a mechanic said, “you can pay me now” ($4 for a new oil filter), “or you can pay me later” ($4,000 for a new engine). $7 million for a single breach is a stiff price to pay for a problem that could have been caused by a simple coding mistake easily caught by early testing. To say nothing of the harder-to-quantify costs to your brand reputation, which may never recover if the breach is serious enough.

So test early and test often.

To learn more about best practices for secure software development and the WebLayers solution, click on the following link to view a brief presentation.

Just came across an interesting article on the need for better testing during software development.  Not surprisingly, the article cites the example of Knight Capital – the $440-million poster child for software glitches – to quantify what’s at stake.

All true, but there’s more to the story.

Our customer experience has shown a truly holistic approach is required to ensure the health of your entire software application portfolio.  WebLayer’s customers are not only automating best practices and testing during the development of new software, but they are also actively analyzing and monitoring their existing applications to uncover any anomalies and “glitches” before they can create performance problems and/or security vulnerabilities.

Improving the overall health of your software can improve the health of your business – and your bottom line.

- Jeff Papows