I’ve long been an advocate for turning software development into software engineering. By this I mean that we need to start following known best practices and using the tools and processes that have been proven to help produce better code. It’s amazing how software developers often ignore standard things that everyone knows makes for better code.
As an effort to promote understanding I’m doing a two-part webinar series with Parasoft on this topic this Thursday the 22nd and next Thursday the 29th. Come join us and learn how getting back to the basics is a great way to harden your software and improve security, safety, and reliability.
The best way to fundamentally improve software is simply to get back to software engineering fundamentals. But reaping benefits from these fundamentals (such as static code analysis, runtime analysis, and unit testing) requires using these practices effectively, and ineffective practices persist at organizations around the world: unit test suites that are noisy are often ignored and hide real issues that will happen after deployment; static analysis that focuses on simple bug-finding instead of real defect-prevention represents a real missed opportunity and forces us to react to software issues rather than take a proactive stance.
In this two-part webinar series, we’ll go into detail on how to reap maximum benefits from fundamental software development practices, showing you how to use them effectively by leveraging Parasoft’s automated testing tools.
In the first session, we’ll concentrate on process, setup, and configuration, to provide you with actionable takeaways around:
- How to harden your code with static code analysis to increase safety and prevent cyber attacks, including which coding standards are the best place to start
- How to add runtime error detection to your testing process to find bugs early and avoid reliability issues in the field
- How unit test automation reduces your effort of creating and maintaining test suites
In the second session, we’ll show you how to integrate automated testing tools into your existing software development process. You will learn how these tools can run as part of continuous integration, inside your favorite development environment. We’ll focus on:
- How to create tests more quickly for C, C++, Java, and .NET by building on ready-made frameworks
- How to win at continuous testing by leveraging automation and analysis
- How to streamline compliance efforts that are normally tedious, with efficiency provided by static code analysis and unit testing
Join us June 22nd and June 29th to see for yourself how easy the fundamentals can be, and how they can help you perfect your software.
When you’re looking for a cybersecurity expert it’s important to be able to spot who knows what they’re doing and who doesn’t. Well in this case the title of the post is a bit of click-bait. Got you, didn’t I? This is really how to spot someone who is NOT a cybersecurity expert. Probably I should have titled it Ten Ways to Spot a Cybersecurity Fake. Let’s take a serious topic and have a bit of fun at the same time. Here’s the list.
- #10 – Mobile phone is more than a year old
- You just can’t push updates to old phones. Unfortunately this is as true for security patches as it is for bug fixes. If you want to be secure you’ve got to keep it patched, and to keep it patched you’ve got to have current hardware. In the smartphone world, this means your phone is less than 12 months old. An “expert” who carries a crappy phone isn’t
paranoid secure enough for me.
- #9 – Still carrying a Blackberry
- The internet age moves fast and you have to keep up. Blackberry is a bit of a dinosaur and you’re just not getting all the latest that you get from more agile vendors. Avoid dinosaurs when looking for technical help, they simply won’t be aware of the latest threats and rely on outdated models of security.
- #8 – Wears a suit
- In the IT industry nothing says sales rep like a suit does. Now this person might understand the need and value of enhanced cybersecurity, but they don’t know what you really need to do. If they’re not a sales rep, then they’re probably just a dinosaur, because tech people don’t wear suits anymore. See above.
- #7 – Wears a tie
- Do I really have to explain? Have you ever met someone who really got cybersecurity who was wearing a tie? See above. (Sorry Kevin – you’re the exception. You rock the cravat.)
- #6 – Uses open wifi
- Any security professional worth their salt is deathly afraid of open wifi. It doesn’t matter if it’s a hotel, a coffee shop, or an airport. Cyberpeople carry their own internet in their pocket.
- #5 – Never uses cash
- Between the Target hack and ATM skimmers at the gas pump, a healthy dose of paranoia when it comes to credit cards is a good idea. I’ve gone back to using cash a lot more than I used to and you should too.
- #4 – Thinks eight characters is enough for a password
- Seriously, rainbow tables people. If your password is leaked in a data breach it can take as little as a couple of milliseconds to crack an 8 character password. If they don’t know this, then their knowledge is years out-of-date.
- #3 – Thinks funny characters you wont’t remember are good for passwords
- I’m sorry but *#*%^)-} isn’t a great password. You will never be able to remember it, you’ll write it down and anyway it’s in a rainbow table so it’s not much better than 12345. You’re better off which an unbelievably long password you can remember that has a few funny tweaks than 8 pieces of gibberish.
- #2 – Doesn’t wear glasses
- Anyone spending their life on a computer has killed their eyes. If they’re not spending their life on the computer, they’re not passionate enough. You want someone who prefers the internet to real life. To paraphrase Orwell “Four eyes good, two eyes bad“
- #1 – Doesn’t use the command line
- Everyone with a hacker mentality uses the command line, regardless of operating system. Anyone without a hacker mentality isn’t qualified to be working in cybersecurity.
I warned you up front we were going to have some fun with this, and hopefully you did. But in reality some of these tips will help you vet your cybersecurity expert. Even just tossing some of the terms above at them to see how they respond may tell you something. If they use a term you don’t know make them explain it – if they can’t explain it they probably don’t understand it very well.
If you don’t know enough to tell a real expert from a fake, get help from someone you can trust, and stay safe out there!
Greetings and Happy New Year. It’s early in the month and we’ve already had our first reported IoT Hall-of-Shame entry, as you know if you follow that page or my twitter @codecurmudgeon. For those who live inside Facebook I’ve decided to make your life easier by adding a Facebook page for the Internet-of-Things IoT Hall-of-Shame as well. That way you can just follow it and it will show up in your Facebook feed.
“Things” are being hacked at a furious pace – some even call it the “Internet of Evil Things”. It’s amazing how often I find out about a new hack every single day. Is your TV going to spy on you? Is it easy to hack your phone? Is the stoplight on your corner vulnerable? Keep up to date on what’s happening.
Go check it out, like the page, follow it for the latest IoT Hall-of-Shame updates, and tell your friends. And when you hear about any IoT devices getting hacked please let me know!
I was honored this week to have the opportunity to present a keynote session at EuroSPI 2016. The title of my presentation was “Software Safety and Security Through Standards” and I discussed one of my favorite soapboxes. That is the idea that software development is often less disciplined than it should be, but it doesn’t have to be. We can and should develop software as an engineering discipline.
One of the key ways to start down this path is to implement coding standards properly. Too many are trying to use coding standards late in the process as a way to find bugs, rather than a way to flag improper methods of coding early on. While the former is cool, the latter is far more valuable.
The adage that “you can’t test quality in a product” is well known, but for some reason in software we think that you can indeed test quality into an application. The same goes for application security, perhaps even doubly so.
In order to break out of the current cycle of code, deploy, fix, redeploy we have to start doing things differently. We have to build a more mature software development process and static code analysis is the way to build upon the body of knowledge and best practices available.
Slides are below. Let me know if you have comments, questions, suggestions. And thanks to everyone at EuroSPI and ASQ for putting on a great conference and allowing me to participate. These are great organizations to get involved with if you’re serious about software quality. I encourage you to check them out.