Imagine having to pay a $218K HIPAA fine. That’s exactly how much a hospital in Massachusetts had to pay because of repeated security failures. St. Elizabeth’s Medical Center had put protected health information (PHI) of nearly 500 patients at risk by using a web-based document-sharing application to store this data without first adequately analyzing the app’s security risks. Not only did they not analyze the app’s security risks, but the hospital also had a lack of adequate security policies. Last year, there was a breach that involved unsecured PHI stored on a former hospital employee’s laptop and USB drive which impacted 595 patients. With all these issues, the hospital will have to fix the gaps in the organization’s HIPAA compliance program along with additional changes such as revised policies and training that need to be submitted to the Department of Health & Human Services. As you can see, enterprise mobility security testing is crucial to your business and shouldn’t be taken lightly.
To begin discussing enterprise mobility security testing, we must first pay homage to the “Seven Layers of the OSI model”. You can’t talk about security testing without mentioning the “Open Systems Interconnection” and its layers: Application, Presentation, Session, Transport, Network, Data Link, and Physical. Application is the seventh layer and Physical is the first layer. Whether you are college-educated or self-taught, if you’ve studied Networking and Security, you know that understanding the seven layers are a great basis for understanding any Network infrastructure. In both web and mobile computing, each layer is vulnerable to various security attacks. With the continuous release of new mobile apps and more people utilizing mobile devices, the excitement and concern of the end user grows daily. Mobile computing has become a way of life for personal and business use so it is important for any company who develops software to have a QA team that is prepared to back them up when necessary. Here are some tips to help baby step your QA team into enterprise mobility security testing:
Being able to peel the onion, that is the OSI model, will give your QA team confidence in mobile security testing. With each layer comes a new level of complexity and precaution you must take to protect it. The Application layer supports applications and end-user processes. You also learn about HTTP, SSH, Telnet and more, within the Application layer. The Presentation layer formats and encrypts data to be sent across a network. The Session layer establishes, manages and terminates connections between applications. The Transport layer provides transfer of data between end systems, or hosts and is responsible for end-to-end error recovery and flow control. The Network layer addresses internetworking, error handling, and congestion control. Within the Network layer, you will also learn about teardrop attacks, also known as denial of service attacks. The Data Link layer encodes and decodes data packets. The Data link layer is also where you will learn about wireless man in the middle attacks. The Physical layer gives hardware the ability to send and receive data on a carrier. The Physical layer is also where you learn more about rogue access points via Wi-Fi connections. Understanding the intercommunication of all of these layers is critical to creating a security testing framework.
When it comes to security testing, the “all hands on deck” approach is the best way to go. By design, many developers have a keen sense for implementing security for the apps they develop. Developers also perform unit tests for those apps and their implemented features. In the simplest terms, unit testing is mostly done to confirm that there are no errors in the code. Unit testing is also done to confirm that a particular feature “works as expected”. This means that unit testing is not always enough to thwart what can happen to the security of software once it is released. As with any software release, whether implementing or testing security is involved in the process or not, it’s not always enough to confirm that software “works as expected”. Having your QA team involved in security testing for any security that you have implemented is vital to the development of that software. They can perform functional testing, usability testing, sanity testing, smoke testing, regression testing, end-to-end testing, acceptance testing, performance testing, install/un-install testing, and more. If you have a QA team that has never performed security testing, the developers that you pair them with can teach them the intricacies of the security they have implemented. In turn, QA team members can help developers create test strategies to break the security of the app in various ways, which will help to create a more viable end product. QA team members can also assist with creating best practices for implementing mobile security. Pairing your QA team members with development is not only good for your product, but it’s also good for moral.
QA team members are responsible for creating test plans and cases for testing. In most cases, each app will require its own test plan and special set of test cases. However, there are very specific aspects of security that should be tested no matter the app. This is where a solid QA security checklist will come in handy. Depending on the app, the checklist can cover, but should not be limited to: user authentication, login validation, and confirming how data gets stored. While some checklist items may still depend on the app needs, it’s always good to set standards. The standards you set for enterprise mobility testing can be based on industry standards as well as company brand standards. Here’s a great article written by the Government Advisory Counsel Executive Writers Bureau. This article nicely outlines very specific precautions that should be taken in mobile security. It also talks about how many networks fall prey to “Man in the Middle” attacks. As many smartphones automatically connect to wifi, it’s easy for the network to connect to a rogue device that is acting as an SSL proxy.
MITM is also known as “Man In the Middle” attacks. A Man in the middle attack is when an attacker secretly relays and possibly alters communication between two parties who believe they are directly communicating with one another. Having your QA team become familiar with third party tools is a great way to help capture possible intrusions. There are many tools and various ways of testing this. One tool I have used for general debugging is called Charles Debugging Proxy. Charles can be used for web and mobile debugging. In addition to standard debugging, you can incorporate Charles into your enterprise mobility security testing as well. You can proxy Charles to your mobile device and have your team confirm whether specific calls are firing and whether the most vital calls are encrypted. For example, if your app is unknowingly making “http” calls during the user login process, you will be able to see the actual username and password entered in Charles. This will immediately alert teams that these calls need to be encrypted using “https”. If you are making unnecessary calls that could make your app vulnerable to attack, you will see those calls firing in Charles as well.
The most valuable thing you can do on your journey to enterprise mobility security wellness is to encourage your QA team to self explore. Some of my recommendations include, but are not limited to: joining security testing groups on LinkedIn and other social media forums, attending seminars, and researching and keeping abreast of any cyber attacks and enterprise mobility app vulnerabilities. Although I mentioned Charles debugging proxy as a possible third party tool, I recommend that QA professionals find a tool that they are most comfortable with since there are numerous tools that exist for such testing. It is important to understand that no one way ensures the security of an app. Security is a continuous process and the more team members you have involved in enterprise mobility security testing, the better.