MASS_25

MassTransit_February_2017

FEBRUARY 2017 | MassTransitmag.com | Mass Transit | 25 Riders are primarily at risk of personally identifi able information (PII) theft , fi nancial theft / fraud and credential theft (i.e., login and password). Th e transit system itself is at risk of attacks on the app’s back-end or cloud-based services, when attackers seek to steal data or disrupt services. Not baking security into the app’s design. Within the information security community, it is well known that an ad hoc and reactive security program (i.e., patching vulnerabilities instead of avoiding them in the fi rst place) is more expensive than designing secure code from the start. When designing an app, refer to the OWASP Top 10 list of mobile app vulnerabilities to make sure every single one of these is accounted for in planning and design. Additionally, consider using a security development lifecycle (SDL) process to ensure the app’s code is secure by design, by default and in deployment. Inadequate security testing. Companies oft en fail to undertake rigorous security testing of a new app before making it public. Testing should include thorough vulnerability scans as well as a “penetration test” (also referred to as a “black box” test) of the app by skilled professionals. A penetration test simulates real-world attacks by criminal hackers and is the best way to make sure the app is suffi ciently secure. However, this type of testing requires specialized expertise, which is why most companies will hire outside security testing fi rms. Using weak or no encryption to protect user data. Developers oft en make basic mistakes with encryption (35 percent of mobile device communications go unencrypted, according to SecureNow), which in this case could expose transit riders to PII and fi nancial theft , account takeovers and more. To avoid this pitfall, make sure the app provides “end-to-end” SSL encryption of all data as it is transmitted between the phone and the back-end server/cloud. (Note: In the past few years, a number of SSL vulnerabilities have come to light. To alleviate this, refer to www. SSLLabs.com for best practices and options for the most secure implementation of SSL.) Data that does not leave the phone (“data at rest”) must also be protected, preferably with encryption that is built directly into the device platform itself. Poor secrets management that exposes credentials, API keys, private certificate keys. Mobile apps regularly expose sensitive data, which criminal hackers can use to compromise the user or the app itself. Attackers will use a number of tricks to try to pull out these secrets, so it is important that the app is fully vetted against them. For instance, does the app accidentally store logins/passwords in a plain-text fi le on the phone? Does it reveal too much information through its logs or crash reports, which hackers can use to fi nd weaknesses in the code? Are credentials hard-coded directly into the app’s code? Th e best recommendation is to avoid storing any secrets, keys, passwords or certifi cates in source code or confi guration fi les as these could be leaked to the public. Unnecessary features that add risks. Limit the app’s features and permission requests to only what is necessary. For instance, a transit authority might be tempted to require access to GPS data on the user’s phone, in order to alert them to nearby transit stops. It might also choose to add web content inside the app, using a feature like UIWebView. However, by increasing the app’s features, a company will also increase its “attack surface” (i.e., more code = more problems), which weakens its security. Additionally, the more private user data that is accessed, stored or utilized by the app means any subsequent breaches could be far more damaging. Failing to develop a security incident response plan. Unfortunately, there is no such thing as 100 percent secure code. Even when security is built into the app from the start, and everything else is done right by the developer team, future vulnerabilities will emerge. It is therefore critical for transit authorities to develop solid contingency plans. Th ese should include three components: (1) have incident monitoring tools in place (such as IDS/IPS, SIEM, exfi ltration monitoring, etc.) that can detect unusual activity on the back-end network as early as possible; (2) designate an internal or external incident response team that can react immediately to any discovered threats; and (3) have procedures and policies in place to limit the damage from a successful attack, such as shutting down parts of the network. In conclusion, transit systems should not be afraid to embrace mobile apps as a new way of connecting with customers, but it is important that they prioritize security. Th e best approach is to assume the app will eventually be breached: developing and operating from this mindset will ensure a high level of preventive and contingency defenses that will limit an organization’s risks. By building security in from the start, testing for weaknesses and planning for the worst, transit authorities can achieve a high degree of confi - dence in their mobile apps. Thinkstock SECURITY SHOULD be built directly into apps to avoid vulnerabilities, as opposed to patching them after a breach. By the Numbers 25% of mobile apps include at least one high risk security flaw - NowSecure 214% increase in new mobile vulernabilities since 2013 - Symantec Chris Weber is co-founder of Casaba Security.


MassTransit_February_2017
To see the actual publication please follow the link above