Make use of OWASP Mobile Top 10

February 14, 2017

OWASP “Mobile Security Project” team updated their Mobile Top 10 Vulnerability list this week. {in the process they broke some of their links, if you hit one, just use the 2015 content for now: https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-2015_Scratchpad}

I was in a meeting yesterday with a group reviewing one facet of an evolving proposal for Office 365 as the primary collaboration and document storage infrastructure for some business operations.

Office 365 in global Financial Services? Yup. Technology pundits-for-sale, tech wannabes, and some who are still intoxicated by their mobile technology have been effective in their efforts to sell “cloud-first.” One outcome of some types of “cloud-enabled” operations is the introduction of mobile client platforms. Even though global Financial Services enterprises tend to hold many hundreds of billions or trillions of other people’s dollars, some sell (even unmanaged) mobile platforms as risk appropriate and within the risk tolerance of all relevant constituencies… My working assumption is that those gigantic piles of assets and the power that can result from them necessarily attract a certain amount of hostile attention. That attention requires that our software, infrastructure, and operations be resistant enough to attack to meet all relevant risk management obligations (contracts, laws, regulations, and more). This scenario seems like a mismatch — but I digress.

So, we were attempting to work through a risk review of Mobile Skype for Business integration. That raised a number of issues, one being the risks associated with the software itself. The mobile application ecosystem is composed of software that executes & stores information locally on mobile devices as well as software running on servers in any number of safe and wildly-unsafe environments. Under most circumstances the Internet is in between. By definition this describes a risk-rich environment.

All hostile parties on earth are also attached to the Internet. As a result, software connected to the Internet must be sufficiently resistant to attack (where “sufficient” is associated with a given business and technology context). Mobile applications are hosted on devices and within operating systems having a relatively short history. I believe that they have tended to prize features and “cool” over effective risk management for much of that history (and many would argue that they continue to do so). As a result, the mobile software ecosystem has a somewhat unique vulnerability profile compared to software hosted in other environments.

The OWASP “Mobile Security Project” team research resulted in the Top 10 mobile vulnerabilities list below. I think it is a useful tool to support those involved in thinking about writing or buying software for that ecosystem. You can use it in a variety of ways. Challenge your vendors to show you evidence (yes, real evidence) that they have dealt with each of these risks. You can do the same with your IT architects or anyone who plays the role of an architect for periods of time — then do it again with your developers and testers later. Business analysts, or those who act as one some of the time should also work through adding these as requirements as needed.  Another way to use this Mobile Top 10 resource is to help you identify and think through the attack surface of an existing or proposed mobile-enabled applications, infrastructure, and operations.

OK, I hope that provides enough context to make use of the resource below.

REFERENCES:

Mobile Top 10 2016-Top 10
https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10

M1 – Improper Platform Usage
https://www.owasp.org/index.php/Mobile_Top_Ten_2016-M1-Improper_Platform_Usage
This category covers misuse of a platform feature or failure to use platform security controls. It might include Android intents, platform permissions, misuse of TouchID, the Keychain, or some other security control that is part of the mobile operating system. There are several ways that mobile apps can experience this risk.

M2 – Insecure Data Storage
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M2-Insecure_Data_Storage  This new category is a combination of M2 + M4 from Mobile Top Ten 2014. This covers insecure data storage and unintended data leakage.

M3 – Insecure Communication
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M3-Insecure_Communication This covers poor handshaking, incorrect SSL versions, weak negotiation, cleartext communication of sensitive assets, etc.

M4 – Insecure Authentication
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M4-Insecure_Authentication This category captures notions of authenticating the end user or bad session management. This can include:
Failing to identify the user at all when that should be required
Failure to maintain the user’s identity when it is required
Weaknesses in session management

M5 – Insufficient Cryptography
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M5-Insufficient_Cryptography The code applies cryptography to a sensitive information asset. However, the cryptography is insufficient in some way. Note that anything and everything related to TLS or SSL goes in M3. Also, if the app fails to use cryptography at all when it should, that probably belongs in M2. This category is for issues where cryptography was attempted, but it wasn’t done correctly.

M6 – Insecure Authorization
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M6-Insecure_Authorization This is a category to capture any failures in authorization (e.g., authorization decisions in the client side, forced browsing, etc.). It is distinct from authentication issues (e.g., device enrolment, user identification, etc.).

If the app does not authenticate users at all in a situation where it should (e.g., granting anonymous access to some resource or service when authenticated and authorized access is required), then that is an authentication failure not an authorization failure.

M7 – Client Code Quality
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M7-Poor_Code_Quality
This was the “Security Decisions Via Untrusted Inputs”, one of our lesser-used categories. This would be the catch-all for code-level implementation problems in the mobile client. That’s distinct from server-side coding mistakes. This would capture things like buffer overflows, format string vulnerabilities, and various other code-level mistakes where the solution is to rewrite some code that’s running on the mobile device.

M8 – Code Tampering
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M8-Code_Tampering
This category covers binary patching, local resource modification, method hooking, method swizzling, and dynamic memory modification.

Once the application is delivered to the mobile device, the code and data resources are resident there. An attacker can either directly modify the code, change the contents of memory dynamically, change or replace the system APIs that the application uses, or modify the application’s data and resources. This can provide the attacker a direct method of subverting the intended use of the software for personal or monetary gain.

M9 – Reverse Engineering
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M9-Reverse_Engineering
This category includes analysis of the final core binary to determine its source code, libraries, algorithms, and other assets. Software such as IDA Pro, Hopper, otool, and other binary inspection tools give the attacker insight into the inner workings of the application. This may be used to exploit other nascent vulnerabilities in the application, as well as revealing information about back end servers, cryptographic constants and ciphers, and intellectual property.

M10 – Extraneous Functionality
https://www.owasp.org/index.php?title=Mobile_Top_Ten_2016-M10-Extraneous_Functionality Often, developers include hidden backdoor functionality or other internal development security controls that are not intended to be released into a production environment. For example, a developer may accidentally include a password as a comment in a hybrid app. Another example includes disabling of 2-factor authentication during testing.


Protect Your USB

September 19, 2016

Physical and logical PC controls still matter.

Just one more reason to resist the shared madness of “bring your own device” and/or “anywhere/anytime/any-endpoint” in global Financial Services.  We hold trillions of dollars for our customers (under the guise of a broad and evolving range of relationships)!  To add value to those relationships, we turn that money into units that are inter-business (and Internet) friendly to enable complex webs of financial transactions and services.  The concentration of “cash” and its transformation into bits results in an attractive target for hostile parties of many types.  How could endpoint anarchy ever be a risk-appropriate behavior for any but a microscopically few roles within our ranks?  It seems like something we should expect to fail the “reasonable person” test.

I was just catching up on some of my random reading and bumped into this demonstration of Windows credential stealing with just 15 seconds of access to a PC’s USB port.

15 seconds of social engineering is not that hard to pull off, so all you have left are serious controls administering the use of your USB ports, physically destroying your USB ports (yes, that is a serious option), along with multi-layer physical & logical security to the location of the PC at any given time.

Take a look st the video below along with the supporting paper.  Then voice your professional opinion and conscience wherever appropriate to resist elevated risk endpoint behaviors.  And if your role permits, ensure that your Financial Services organization has the goals and resources to effectively deal with attacks like the ones enabled by this automated, USB enabled assault.

REFERENCES:

15 Second Password Hack, Mr Robot Style
Video:
https://www.hak5.org/episodes/season-21/hak5-2101-15-second-password-hack-mr-robot-style
Supporting Paper
https://www.hak5.org/blog/15-second-password-hack-mr-robot-style


Recognize the Fact of Android Endpoints

April 20, 2016

The BYO hypesters that I am exposed to tend to trend strongly toward all things Apple.

Earlier today, a ranking security leader saw a slide highlighting the history of iOS and OSx vulnerabilities and snapped something about the market speaking through Apple’s sales dominance… …as if Apple ‘owned’ our customer, prospect, and employee population.

This seems to happen a lot. I work for an overtly “global” financial services corporation. Leading technologists on staff promote Apple products as the solution to virtually any endpoint challenge (we currently do our business on tens of thousands of Windows endpoints running Windows applications…). The company that pays us is attempting to generate strategic expansion in Latin America and Asia…  We want and need to service people’s financial services needs where they are — meaning strong support for interactions via their mobile devices.  The mismatch is cringe-worthy.

How does this marketplace blind spot afflict so many people who otherwise are intelligent adults?  I really don’t know.  Maybe financial services professionals are becoming prisoners of their own cognitive traps?

MacRumors recently announced that “iOS and Android Capture Combined 98.4% Share of Smartphone Market.” The Apple portion of that global 2015 market share was 17.7% (down from 20.4% in 2014). Android-based mobile devices represented 80.7% of the 2015 market (up from 76.0% in 2015).

Year after year people around the world purchase more Android mobile devices than the competing Apple devices. In 2015 that amounted to more than 4.5 Android mobile devices purchased for every Apple iOS device sold.

Gartner (Feb 2016) reported:

Worldwide Smartphone Sales to End Users by OS in 4Q15 (in Thousands of Units)

           4Q15     4Q15 Market   4Q14      4Q14 Market
        Units Sold  Share %     Units Sold  Share %
Android 325,394     80.7        279,057     76.0
iOS      71,525     17.7         74,831     20.4
Windows   4,395      1.1         10,424      2.8
Blackberry  906      0.2          1,733      0.5
Others      887      0.2          1,286      0.4

 

Sure, the Android == ‘security hell’ meme has some good reasons for retaining its foothold in business culture. And sure, there are many more ‘ancient’ unpatched/underpatched Android devices compared to the iOS environment. There are attractive and repulsive characteristics of Android/iOS environments that we can argue about, but that avoids the fact that our employees, customers, and prospects buy and use more Android devices.  A lot more.  We will leave a lot of money on the table if we ignore that fact and build software & operations that are tightly-coupled with Apple mobile device products.

OK. I had to get that out of my system…

REFERENCES

“iOS and Android Capture Combined 98.4% Share of Smartphone Market.”
By Joe Rossignol, Feb. 18, 2016
http://www.macrumors.com/2016/02/18/ios-android-market-share-q4-15-gartner/

“iPhone lost market share to Android in every major market except one.”
Jim Edwards, Jan. 27, 2016
http://www.businessinsider.com/apple-ios-v-android-market-share-2016-1


Another Demonstration of How Mobile Phones & their Supporting Networks are Vulnerable to Abuse

April 17, 2016

Some continue to hype “bring your own device” (sometimes just BYOD) as near-term technology and business goal for global Financial Services enterprises.  At its most shrill, the argument hammers on the idea like ‘we all have a smart phone and it has become the center of our lives…‘  In this industry we are all responsible for protecting trillions of dollars of other people’s money as well as digital information about customers (individuals & companies), partners, and deals, all of which must remain highly secure, or the foundation of our business erodes.  That responsibility is wildly out of alignment with most BYOD realities.  In that context, this blog entry is an offering to help risk management teams educate their Financial Services organizations about some of the risks associated with using mobile phones for work activities.

Here is some content that may be useful in your security awareness campaign…

Financial Services executives “private” communications could be of high value to cyber criminals. So too could be your Finance staff, Help Desk, Reporting Admin, Database Admin, System Admin, and Network Admin communications. There are a lot of high value avenues into Financial Services organizations.

Under the title “Hacking Your Phone,” the 60-Minutes team have security professionals demonstrate the following in a 13 minute video:

  • Any attacker needs just their target’s phone number, to track the whereabouts, the text traffic, and the details of phone conversations initiated or received by their prey. Turning off your “location status” or other GPS technology does not inhibit this attack. It depends upon features in the SS7 (Signalling System #7) network that have been overly permissive and vulnerable to abuse for decades. These SS7 vulnerabilities appear to remain after all this time because of nation-state pressures to support “lawful interception.”
    They demonstrate their assertion in an experiment with U.S. Representative Ted Lieu, a congressman from California.
  • Attackers can own all or some of your phone when you attach to a hostile WiFi. Never trust “public” or “convenience” (for example “hotel”) WiFi. Attackers present look-alike WiFi (sometimes called “spoofing”) and then use human’s weakness for “trustworthy” names to suck targets in.
    They demonstrate this approach by stealing a target’s mobile phone number, account ID, and all the credit cards associated with– with that account, along with their email.
  • Attackers use social engineering to get their software installed on targeted devices. One outcome is that they can also monitor all your activity via your mobile phone’s camera and microphone — without any indication from the mobile device screen or LEDs, and the attacker’s software does not show up via any user interface even if you tried to find it.
    They demonstrate this approach with the 60 Minutes interviewer’s device.

Remember, not everyone employed throughout Financial Services enterprises understands the risks associated with performing business activities via mobile devices.  Use materials like this video to augment your risk awareness program.

REFERENCES:
“Hacking Your Phone.” aired on April 17, 2016
http://www.cbsnews.com/news/60-minutes-hacking-your-phone/

SS7, Signalling System #7 https://en.wikipedia.org/wiki/Signalling_System_No._7

Lawful interception.” https://en.wikipedia.org/wiki/Lawful_interception

 

 


Complex Problems Remain

October 4, 2015

All of us involved in global financial services continue to be confronted with an expanding universe of “cloud” and “mobile” and “agile” options. Too many marketers for too many of these vendors seem to exercise increasingly predatory behaviors. A key result seems to be an escalation of risk management complexity…

In that context, I have been working on some complex issues…
Hofstadter’s Law (1979) still applies.

Hofstadter’s Law states that “It always takes longer than you expect, even when you take into account Hofstadter’s Law.”

REFERENCES:
Hofstadter’s Law: https://en.wikipedia.org/wiki/Hofstadter%27s_law


Another Reason to Disbelieve The Apple Security Story

September 2, 2014

Some subset of any Financial Services organization’s workforce has BYOD fever.  For many in our business, that fever has infected one or more senior leaders who cannot be ignored.  In Financial Services, we are collectively responsible for protecting $trillions of other people’s assets.

Most of the BYOD fever seems to be associated with new mobile devices.  From what I can observe, many Financial Services organizations are emphasizing their attraction to Apple iPads over Android or other alternatives.  That behavior seems out of phase with our due diligence obligations.

Apple has invested what must be a tremendous amount of resource and effort in building an image that incorporates something like “trust me, but I will not respond to your requests for transparency…”  For some reason, that seems to work.  This is in spite of regular patching of vulnerabilities that could have been discovered at architectural analysis, design, coding, static code security analysis, QA or penetration testing.  Apparently those activities do not incorporate effective secure software practices.

The latest example of Apple’s approach to software security made the news over the last weekend.  A vulnerability in iCloud enabled a trivial attack to discover the passwords of a number of targeted individuals.  Those passwords were then used to steal those user’s iCloud “protected” personal files.  Apple did not enforce a “max attempts” threshold for failed attempts to login to iCloud, which permitted attackers to pound away at the URL https://fmipmobile.icloud.com/fmipservice/device/$apple_id/initClient with basic auth attempts using scripts or malware that identified itself as ‘User-Agent’: ‘FindMyiPhone/376 CFNetwork/672.0.8 Darwin/14.0.0’.   An easy-to-understand proof-of-concept application is available on github.

Remember, in Financial Services, implementing some type of failed-login governor has been standard practice since we have been using the Internet for business.  Our constituents expect some type of “n-failed-login-attempts-and-you-are-locked-out.”  They may not consciously think through a detailed rationale, it is just a small but essential part of exhibiting a threshold level of Financial Services due diligence.  I assume that one possible root cause was that Apple engineers and architects must have reasoned that either nobody could format a basic auth HTTP POST with some json payload and sling it at their iCloud web service interface, or they believed that their closed ecosystem and black box approach to security implementations would keep their web service interface from being discovered.  Alternatively, they specified a max-failed-login-attempts feature into iCloud designs, but Apple management directed them to remove it based on non-technical rationale.  There could be other root causes of this vulnerability, but with the resources available to Apple, none seem in alignment with their “trust us” story-telling.  Their iCloud authentication implementation was just not fit for Financial Services workforce operating environments — while they have been arguing that “”iCloud is built with industry-standard security practices and employs strict policies to protect your data.”

Brute forcing passwords is a proven, decades-old practice that is highly effective unless resisted (because people, in large numbers, behave so predictably).  Financial Services-grade businesses understand this and implement and enforce policies that generally resist bald, brute force attacks.  It is a small, simple, basic, and essential characteristic of any Internet-ready system hosting non-public resources.  The fact that Apple implemented an Internet-facing authentication interface without resistance to brute force password attack, then failed to implement defense in depth (i.e., instrument the environment with effective IDS/IPS, identity fraud detection, and more) demonstrates — again — their unfitness for the Financial Services workforce environment.

Update 09-03-2014:

Could it be that Apple considers hackappcom’s proof of concept application and demonstrations of its use just another side-show?  They reacted to news about the celebrity data theft using what I read as legalistic and deflecting language:

“None of the cases we have investigated has resulted from any breach in any of Apple’s systems,” Nat Kerris, a company spokeswoman, said in a statement. “We are continuing to work with law enforcement to help identify the criminals involved.”

Update 09-06-2014:

Apple, via CEO Tim Cook continued the Apple ecosystem and its technology are safe theme, blaming users for the recent iCloud vulnerabilities and their exploit, saying in a WSJ interview that Apple would ratchet up user awareness communications about stronger and safer passwords, and apparently will not be investing in more effective engineering:

“When I step back from this terrible scenario that happened and say what more could we have done, I think about the awareness piece,” he said. “I think we have a responsibility to ratchet that up. That’s not really an engineering thing.”

Mr. Cook also said that Apple would would begin sending users email messages and push notifications when certain AppleID events occur or when a user’s account data lands on a new device.

After a 40-hour investigation “concluded that there was no breach of its data servers. The company has said it discovered a number of celebrity accounts were compromised by targeted attacks…”

Sure.  Not ready for Financial Services.

 

REFERENCES:

“Hacker leaks dozens of nude celebrity pics in alleged iCloud hack.”
By Cody Lee, Aug 31, 2014
http://www.idownloadblog.com/2014/08/31/icloud-celeb-nude-pics-hack/

“Apple reportedly patches Find My iPhone vulnerability to hack Apple ID accounts.” By Christian Zibreg, Sep 1, 2014
http://www.idownloadblog.com/2014/09/01/icloud-hacking-patched-find-my-iphone/

“ibrute.” By hackappcom
https://github.com/hackappcom/ibrute

“Apple patches ‘Find My iPhone’ exploit.” By Adrian Kingsley-Hughes, Sep 1, 2014
http://www.zdnet.com/apple-patches-find-my-iphone-exploit-7000033171/

“iCloud: iCloud security and privacy overview.”
http://support.apple.com/kb/HT4865

“iCloud Keychain.”
http://www.slideshare.net/alexeytroshichev/icloud-keychain-38565363

“Privacy Collides With the Wild Web.” By Mike Isaac, Sep 2, 2014
http://mobile.nytimes.com/2014/09/03/technology/trove-of-nude-photos-sparks-debate-over-online-behavior.html?_r=0 (downloaded Wed 09/03/2014 5:46 AM)

“Apple Says It Will Add New iCloud Security Measures After Celebrity Hack.” By Brian X. Chen, Sep 4, 2014 http://mobile.nytimes.com/blogs/bits/2014/09/04/apple-says-it-will-add-new-security-measures-after-celebrity-hack/

“Tim Cook Says Apple to Add Security Alerts for iCloud Users — Apple CEO Denies a Lax Attitude Toward Security Allowed Hackers to Post Nude Photos of Celebrities.” By Daisuke Wakabayashi, Sep 5, 2014 http://online.wsj.com/news/article_email/tim-cook-says-apple-to-add-security-alerts-for-icloud-users-1409880977-lMyQjAxMTA0MDAwNDEwNDQyWj

“Apple Media Advisory: Update to Celebrity Photo Investigation.” http://www.apple.com/pr/library/2014/09/02Apple-Media-Advisory.html (downloaded Sat 09/06/2014 5:56 PM)


Another Remote Access-Enabled Breach

August 20, 2014

The same tools that help our workforce remain productive when outside their brick-and-mortar place of business are being exploited by cyber-criminals to break into business’s computer networks (I wrote about one facet of this issue late last week). Today we learned that this led to the theft of customer credit and debit data at 51 UPS franchises in the United States. Recently we read about it being used to hack into retailers like Target and Neiman Marcus.

In a recent report the Homeland Security Department warned that hackers are scanning Internet-accessible systems for remote access software. They appear to be omnivores, targeting platforms made by Apple, Google, LogMeIn, Microsoft, Pulseway, and Splashtop that help remote workers to access business computer networks over an Internet connection.

When the hostile actors identify targeted remote access software, they install malware and then have means to effectively ‘guess’ login credentials — or in some situations, the endpoint hosts unauthenticated remote access, requiring no password at all. Once the hostile actors acquire a foothold, they have a difficult-to-detect entry point into business networks.

Under any circumstances this is a problem, but for endpoints used by members of the workforce having elevated rights — consider database analysts, finance administrators or executives, investment pipeline or their back office settlement personnel, top-tier executives, and more (for most financial services enterprises the list goes on and on) — the potential for material harm is real and present.

In that context experts recommend:

Remote Desktop Access

  • Configure the account lockout settings to lock a user account after a period of time or a specified number of failed login attempts. This helps to resist unlimited unauthorized attempts to login whether from an unauthorized user or via automated attack types like brute force.
  • Limit the number of users and workstation who can log in using Remote Desktop. Perform risk assessments to help determine access.
  • Use firewalls (both software and hardware where available) to restrict access to remote desktop product/service listening ports (TCP 3389 et.al.).
  • Change the default ‘remote desktop’ listening port(s).
  • Define complex password parameters. Configuring an expiration time and password length and complexity can decrease the amount of time in which a successful attack can occur.
  • Require strong two-factor authentication (2FA) for remote desktop access.
  • Install and professionally-manage a ‘remote desktop’ gateway to restrict access.
  • Add an extra layer of authentication and encryption by tunneling your remote desktop through enterprise-managed IPSec, SSH or SSL.
  • Require strong two-factor authentication when accessing sensitive networks. Even if a virtual private network is used, it is important that strong two-factor authentication is implemented to help mitigate the risks associated with keylogger or credential dumping attacks.
  • Severely limit administrative privileges for remote users and applications.
  • Periodically review systems (local and domain controllers, and the rest of your directories) for unknown and dormant users.

Network Security

  • Review firewall configurations and ensure that only allowed ports, services and Internet protocol (IP) addresses are communicating with your network. This is especially critical for outbound (e.g., egress) firewall rules in which compromised entities allow ports to communicate to any IP address on the Internet. Hostile actors leverage this configuration to exfiltrate data to their IP addresses.
  • Segregate sensitive network segments from other networks.
  • Apply access control lists (ACLs) and other traffic verification technology on router configurations to help enforce defense in depth used to limit unauthorized traffic to sensitive network segments.
  • Create strict firewall rules and ACLs segmenting public-facing systems and back-end database (or other) systems that house sensitive non-public data.
  • Implement data leakage prevention/detection tools to detect and help prevent data exfiltration.
  • Implement tools to detect anomalous network traffic and anomalous behavior by legitimate users (compromised credentials).
  • Actively monitor, respond to, and follow through on security alerts.

REFERENCES:

“Checking In From Home Leaves Entry for Hackers.” By Nicole Perlroth, 07-31-2014. http://www.nytimes.com/2014/07/31/technology/checking-in-from-home-leaves-entry-for-hackers.html?_r=0

“Alert (TA14-212A) — Backoff Point-of-Sale Malware.” 07-31-2014 & Last revised on 08-18-2014 https://www.us-cert.gov/ncas/alerts/TA14-212A

“United Parcel Service Confirms Security Breach.” By Nicole Perlroth, 08-20-2014. http://mobile.nytimes.com/blogs/bits/2014/08/20/ups-investigating-possible-security-breach/

“Another BYOD Security Challenge – User-Managed Remote Access Software.” https://completosec.wordpress.com/2014/08/16/another-byod-security-challenge-user-managed-remote-access-software/

“Another BYOD Security Challenge — User-Managed Remote Access Software.” https://completosec.wordpress.com/2014/08/16/another-byod-security-challenge-user-managed-remote-access-software/

“Keylogger Revealed in the Apple iOS Ecosystem.” https://completosec.wordpress.com/2014/02/25/keylogger-revealed-in-the-apple-ecosystem/

“BYOD = Bring Your Own Demise?” https://completosec.wordpress.com/2013/06/22/byod-bring-your-own-demise/

“Another Reason to Resist BYOD Using Consumer Mobile Devices.” https://completosec.wordpress.com/2013/07/04/another-reason-to-resist-byod-using-consumer-mobile-devices/


%d bloggers like this: