What intruders do your applications let in?
Have you ever heard the idiom "Can't see the forest through the trees?". Well friends, get your chain saws out because we need to start clearing the brush at the I.T. front door before we can look anywhere else. For the next few blog postings we are going to discuss the security risk of internal applications.
Most businesses have a blind faith that their internal applications have the proper security. They then spend billions keeping the network secure. Keep in mind the most common crime is when a paid hacker finds a loophole in application software—not your network.
I'm not saying developers are building back door trojans like in the ‘70s. I'm talking about hackers that look at the data stream to see if their unencrypted characteristics or patterns are now showing up over wireless networks. One way these hackers gain access to your system is through applications.
Let’s say you found this application that looks interesting (let’s call it angry, ninja, jetpack with friends) and you install on your phone and then hook it up to your computer to recharge. Most companies allow employees to use their cell phones at work, but in reality, by allowing this they just tethered their secure computer to an open and unsafe network.
What are you letting in through the BYOD door?
The reality is that development tools, and third-party software and applets can pose a bigger risk to companies' security than the application which they created. In addition, I’ve always heard that data or information is the most important asset a company owns. I would say that if a hacker gets a hold of the code, he or she can get access to the data and much more.
I know that I'm only restating the obvious "Chicken or the Egg" scenario. I need to make a point of the use of code to manipulate data. Case in point, how many applications in your shop use freeware or shareware either as a tool or as an applet embedded into the application? The truth is that most companies don't recognize how exposed their code is. The companies that do test only test the application when it is going into production. I would guess that most developments implementations are not tested because they are considered tier two applications—leaving you open to attack.
In both the Drop Box and Yahoo cases of hacking, it wasn’t the front end of the database using SQL code that was hacked. Hackers found the code and got the data. Please secure and encrypt code when transporting your code. If your current code repository isn’t encrypted, find one that is.
At this time, it's hard to compete with freeware or even shareware when you need a tool or applet fast to complete development of an application. If you download them do you take security steps to ensure security or do you just install it on your local computer and then forget about it. When you compile applications do you know what everyone of the "OCXs" and "DLLs" does in the application? In agile IT environments, we are required to develop applications faster. This requires developers to reach outside the peer network, which is ok but could be a security risk. We all heard the story that nothing is free; but please, don't be the one that has to pay.
Other Blogs you may like:
- Putting Stabilizers in test automation and test execution?
- Defining a Project in Application Lifecycle Management or Quality Center
- Attended and unattended testing
- OOP’s is the best way to describe Business Process Testing?
- HP Sprinter - Improving Quality without Automated Testing
- Doc meeting one of the tallest men in I.T.