devopsy.kinsta.cloud

Tag: PII

  • Top iOS Security Gotchas

    Top iOS Security Gotchas

    Ensuring the security of user data within your app is critical to building trust in your business and contributing to the online safety of customers.

    Here’s a list of the top 10 essential security mechanisms that Apple offers to up the security posture of your iOS applications. Adopting these technologies and APIs within your products is an effective step toward writing more secure applications, giving you a lower risk of potential data compromise and increased confidence in your security posture.

    Opting Out of System Data Protection

    iOS provides the data protection setting, a robust way to automatically encrypt any files created by your app. This is an important security setting, however, it is turned off by default and many developers never enable it. Leveraging the system’s data protection mechanism is an easy win for increasing the security of user data within your app.

    Transmitting Data Over Insecure Connections

    It’s critical to ensure that any data-in-flight is transmitted over secure connections. By using encrypted HTTPS connections for all apps’ network activities, a wide variety of data-in-flight compromises are mitigated. Additionally, organizations are recommended to leverage SSL pinning for maximum transport-layer security.

    Deserialization Fails

    The default protocol to serialize and deserialize data on iOS, NSCoding, is vulnerable to object substitution attacks, which could potentially allow an attacker to gain remote code execution. Apple offers a near drop-in replacement, NSSecureCoding, which is not vulnerable to this attack. To convert a serialized class to use the NSSecureCoding mechanism, Apple has outlined steps in its documentation. Making the recommended changes allows the system to enforce safe deserialization.

    Opting Out of App Transport Security

    App Transport Security (ATS) is a mechanism provided by Apple to mediate all network connections made by the app and validate that data is being transmitted securely. Opting out of ATS by use of NSAllowArbitraryLoads, or similar exemptions, is an easy way to shoot yourself in the foot and turn off a powerful security mechanism.

    Cryptography API Misuse

    Encrypting user’s data is a no-brainer, but care must be taken to ensure that it’s done in a cryptographically secure way. Some system APIs, such as CommonCrypto, are easy to misuse. This results in the illusion of security, while still allowing an attack vector for user data to be compromised. Be sure to use these APIs with secure options, and never statically embed encryption keys or use an encryption key which is trivially derived.

    Leaking PII to NSUserDefaults

    When handling personally identifiable information (PII) within an app, it can be tempting to store it in a convenient and straightforward way, such as using an NSUserDefaults entry. However, this approach allows any other app on the device to read this potentially sensitive data. Sensitive data, especially identifiable user information, should always be stored in a secure location, such as the device’s keychain, and encrypted when necessary.

    Unsafe Keychain Usage

    While the keychain is the most secure store of data on the Apple device, developers must still take care to ensure they’re using it correctly. It’s possible for developers to save data to the keychain in such a way that the data is always unencrypted and accessible, even when the device is locked and data would otherwise be encrypted. When saving sensitive data to the keychain, ensure that you’re using the strongest possible data-protection settings to maximize security.

    Wherever possible, utilize “kSecAttrAccessibleWhenUnlocked,” the strongest protection class, when saving items in the keychain. This protection class tells the system that data should be encrypted when the user is not actively using your application. If your app needs to access this data while running in the background, you may need to fall back on the “kSecAttrAccessibleAfterFirstUnlock” protection class, which ensures the data is encrypted only until the user has unlocked the device after boot.

    Embedding Vulnerable SDKs

    When an SDK is linked into your application, you’re also implicitly exposing your app to any potential vulnerabilities in the SDK. Compromised SDKs have led to a variety of mobile app attacks, such as a vulnerable AFNetworking version leading to data compromised through a MitM attack. Without a security audit of the SDKs used within the app, developers are blind to the potential vulnerabilities they are introducing.

    Allowing Third Party Keyboards on Sensitive Input Fields

    While installing third party keyboards are useful for user customization, they introduce a new vector for data leakage. This is because the developer of a third party keyboard may be able to extract any information typed on the keyboard. As a result, it’s in the user’s best interest to disable these keyboards when handling sensitive data, such as identifiable information or credit card numbers.

    Leaking PII to Device Logs

    It’s all too easy to leave debug logging, which may include PII, in production builds. Before release, validate that any log statements which might include sensitive data are scrubbed from the code. This might be achieved by way of flags, which only enable these log statements in debug builds. Since logs may be visible to anyone with physical access to the device, it’s paramount to exclude sensitive data from them.

    Since adopting the newest technologies often introduces unforeseen risks, defensive security is a constant endeavor. However, following these top 10 tips will increase your organization’s security posture and reduce vulnerabilities introduced by iOS risks.

  • Six Steps Every Business Should Take to Protect Its Data

    Six Steps Every Business Should Take to Protect Its Data

    Data may or may not be the new oil but it is the growth engine of today’s digital age. Data about a company’s customers, products, services and sales is worth a lot to the company itself, of course, but also to its competitors, as well as to business-savvy hackers. This is why every business, regardless of size, needs to protect its data. 

    Once created, data never really dies, and it is used in multiple ways. In fact, the more data is used for making decisions, the more valuable this asset becomes to you and everybody else.  

    Protecting something of such value requires a different strategy–we need to start from the data itself. This may look complex but here is an easy way of thinking about that process.

    What Data Do You Have?

    Knowing what sensitive data your company is generating and storing sounds like a no-brainer, but many businesses don’t have a good handle on the different types of data they create, copy, use or store. You may not realize, but some of your data might include personally identifiable information (PII), healthcare data and financial data. As you are a custodian of such data, this requires special attention not only to protect your users, but also to satisfy compliance regulations. If you do not know your data, you cannot quantify your risk, and hence cannot prioritize your limited resources and time.

    Where Is Your Data?

    If you don’t know where your data is, you cannot protect it. And many times, even IT staff aren’t exactly sure where sensitive data resides. Your data could be in databases, file systems, applications or archives. For a hacker, these are all ripe targets, not to mention the four, eight or more copies of the same data distributed across less protected test, development, disaster recovery and backup systems. In addition, fragments of your sensitive data often get distributed across dozens of interlinked or even disconnected systems. If that sounds odd, think of your own personal information. Some of those bits may sit in email, Word and Excel, along with text messages, sticky notes and notebooks. Now, extrapolate this to a company of thousands of employees, and recognize that hackers need to get access to only one of those sources.

    Who Has Access?

    It is important to understand who your users are, and what access they have. Many companies give too much access to too many people, and worse, they do not know about how many keys have been distributed across the company, and to whom. Instead, companies should limit access to as little data as possible, and assign rights on a strict “need-to-know” basis. The fewer the people with limited access, the lesser the chance that they copy, share or contaminate that data. Even if a hacker were to take over their account, your loss would be limited.

    Who Touched Your Data?

    Understanding where your data is and who can access it is a great starting point, but you need to monitor actual data access to detect anomalies and unauthorized usage. Given that threats and vulnerabilities are always evolving, you may not be able to stop all of them, but detecting intrusion can allow you to intervene and limit the loss. Companies should audit users who log on to their systems, and track what they are doing, especially if they have administrative access to those systems or have broad access to sensitive data. It’s not that you do not trust them, but blind trust without verification can be exploited—especially by hackers masquerading as them.

    Why Keep Doors Open?

    A bank with broken windows or weak locks on side doors invites intruders. It is critical to lock down your systems by reviewing your configuration settings, patching your systems, closing unused services/ports and locking down critical data. Hackers today have sophisticated automated tools that can quickly scan systems for gaps and vulnerabilities. If they are going to map out your IT systems, don’t you want to scan them and fix them before they come probing? The more exploitable the holes in your system, the faster a hacker’s ROI.

    Why Use Real Data?

    It certainly is easy to test applications against real data, but doing so creates copies of data that your organization was already having trouble protecting. One simple way to reduce risk is to use fake-but-real-looking data for testing and development purposes. This means systematically replacing all occurrences of real social security, credit card numbers, email addresses, financial information and health data with unrelated random data. Using fake data not only limits exposure to the testers and developers, but also mitigates damage should someone gain access to the test system.

    Protecting data isn’t just about setting up the firewall or installing anti-virus software on your endpoints. To most adversaries, these are just speed bumps. Protecting data requires starting from the time of creating data, discovering what you have, knowing where it is stored, enforcing access rights and tracking its usage.

    As custodians of the valuable data that never dies, we need to have a strategy around completing these tasks in a scalable and repeatable manner. Status quo is not an option in an age where breaches are the stuff of near-daily headlines.

    We hope you never become a target of any attacks, but in case you do, understanding your sensitive data and being proactive in protecting it can make the difference between a quick recovery and a drawn-out nightmare.

    — Vipin Samar