Rawpixel - Fotolia

Fight new IT security issues with brawn and brain in operations

IT systems have changed, development processes have changed and even the business's customers' habits have changed. Why hasn't IT security?

The cloud and serverless movement has indeed changed the way developers and IT, and thus DevOps teams, work.

Cloud-based microservices can shrink dev cycles to near real time -- many companies are doing multiple deployments in a single day across dozens or hundreds of microservices. This makes for some very happy developers, and even happier marketing teams, since they can deliver new features quickly, but they can miss dangerous IT security issues. When moving at such a rapid speed, enterprises must ensure developers aren't accidentally exposing sensitive information to potential hackers.

How do we know that we're not screwing something up when we're moving so fast? Consider all the high-profile hacks, and how long it took the company to find the leak. Monitoring and detection of IT security issues shouldn't take six months. If we're moving fast on the dev end, why aren't we moving as fast on production tracking?

Cloud communications vendor Twilio operates with a DevOps culture and full-stack engineers responsible for code through production. In 2016, the company launched nearly 8,000 updates, while still achieving 99.999% availability. How can every business adopt this style? How can we also make sure that, in addition to availability, we preserve functionality and protect users' information?

Tests only tell half of the story

If we're moving fast on the dev end, why aren't we moving as fast on production tracking?

For reliability and availability, every development methodology needs integration tests. Tests are typically built to prevent regressions, or make sure code does what's expected with input that developers can predict. But what about input that isn't predictable? Did you anticipate a user sending a null character followed by a Unicode control character? Are you logging that sort of information?

IT teams can test a lot of scenarios by simultaneously sending input to production and staging environments; however, they risk accidentally modifying production databases in the staging environment and must take precautions. For example, to test a credit card hack, don't charge a customer's credit card -- instead make sure it's using Test keys for stripe. Don't send out email messages to customers -- instead message a testing account that can verify things worked properly. Five nines reliability is great, but if an admin can't invite someone to join an application because he didn't set their name, and the email template fails when a name isn't set, that's still a partial outage in terms of user experience.

Simplicity is key in IT security planning

The worst thing to do to any application is build in more potential security holes by adding features that aren't necessary or are hardly used. Why have an application programming interface (API) to expose a user's email address and hashed password for a quick login functionality? Did you add a chart into your system to show some usage stats, but accidentally expose what individual users are searching on? Is that new Text this story functionality something readers actually wanted, or is it just exposing your company to become an unknowing spammer?

Simple systems present fewer IT security risks, and it's important to not reinvent the wheel whenever possible. Don't worry about creating your own two-factor authentication when ready-made TFA implementations exist from Auth0 or Stormpath.

When systems get more complex, a little planning to keep individual components compartmentalized prevents issues. A front-end system doesn't need to know password hashes for the currently logged in user. The recommendation engine just needs a user ID, not the email address or credit card information for a user. Most importantly, analytics services, such as Google Analytics, don't need user IDs that include an email address or social security number.

Cloud host focuses on DDoS

Amazon Web Services designed Shield and Web Application Firewall (WAF) to prevent IT security issues caused by distributed denial of service (DDoS) attacks. Shield is an automatically enabled managed service that detects and automatically mitigates threats to applications hosted on AWS. WAF can help with application-level DDoS attacks. These types of services should become standard everywhere to help block hackers. While both add availability assurances to the stack, neither can prevent an attacker from targeting a vulnerability in the AWS customer's code that exposes user data.

The future is AI intrusion detection

Intrusion detection systems (IDS) are common in high-level enterprises. They can be great to detect when an IT security event occurs, but they're not perfect and they've been proven to be fooled in the past -- how long did it take Target to identify that it had been hacked? Advancements with artificial intelligence and AI IDS offerings are amazing and prolific, however we're not there yet. When IDS options can monitor application logs in real time as well as sit atop open APIs and websites, we'll see the next generation of security.

For examples of how to prevent IT security issues in the future, look to some of the new Google reCAPTCHA settings. If a CAPTCHA system believes you may be a robot, it makes you enter a code; if not, you can continue on without needing to perform any complex human-specific task. Similar techniques should be applied to all other accesses of systems to capture and block possible intrusions in real time.

What's in the app?

In the end, there's one thing every IT team must know: If someone wants badly enough to hack into your system, they will. There's no stopping someone who dedicates enough resources to get into a system, but take heart -- most likely you're not the target of a foreign government. Some security precautions are just too much for normal businesses to handle, and there's always a tradeoff between an allowed amount of security risk and ease of use. If you wait for the system to become 100% hackproof, it'll never get launched.

There is some accountability every system needs. If it's easy enough for one hacker to break into the system within a day, the company running that system is at fault. Faster development can lead to carelessness, so take some precautions from the IT security experts.

Gauge how much security a system needs based on what it's storing. If it stores credit card information, double down on securing the infrastructure and application. If it stores email addresses along with some public copy someone wrote, that doesn't require nearly as much security. Any time email addresses and passwords are stored, however, encrypt the passwords. You don't want to hand a hacker a list of all email/password hashes in the system. Users often share passwords across multiple programs and services, so if your system is exposed, you must notify users as soon as it's detected so they can protect their online identity elsewhere.

Next Steps

Expect salary increases for IT security positions in 2017

IT security basics to interrupt the breach cycle

Make IT security a habitual task for best results

Dig Deeper on IT Ops Implications of Continuous Delivery