Tag: Security

Categories
Community

Where does Security sit in Early-Stage Software Development: the Shift Left Approach

Security in Early-Stage Software

The average cost of a security breach in a hybrid cloud environment is estimated at a staggering $3.6 million making it critical for organisations to make software security one of the most important priorities.

Cisco’s most recent report, based on the findings from two SlashData global surveys that targeted enterprise developers, uncovers developers’ exposure to API security exploits, their outlook on security, and how they use automation tools to detect and remediate threats. Here is a detailed preview of the report:

  1. Enterprise developers focus on prioritising security from the early stages of development

There is a significant rise in security threats; in fact, 58% of enterprise developers have had to tackle at least one API exploit in the past year alone. And to make matters worse, nearly half of them have experienced multiple API exploits during that time.

As modern applications increasingly rely on microservices, securing the APIs that connect these services becomes even more crucial. It is also true that juggling multiple APIs can make staying on top of security challenging. That’s why it’s essential to prioritise security from the very beginning of development to avoid wasting time and effort on reworking code and dealing with exploits later on.

Obviously, breaches should be ideally prevented. But if they do occur, organisations must be set up to act swiftly. According to the report, ,only one-third of enterprise developers can resolve API exploits within one day of a breach.

Security in Early-Stage Software

By treating security as a top priority from the start of the development lifecycle, organisations can increase preparedness and avoid costly mistakes down the road.

2. What is the right time to address security concerns?

Shift-left security is all about strategically placing security at the forefront. The cost savings from addressing security concerns early in the development process can be significant compared to dealing with security issues during deployment or after a security breach. In fact, according to the data, many organisations are already putting significant effort into identifying security vulnerabilities during the early stages of development, and as a result, have implemented additional security measures.

How do enterprise developers address security?

Security in Early-Stage Software

3. Relying on automations can account for faster, and frictionless operations

During the surveys, developers were asked whether they use automated approaches to security, such as scanning tools or automated fixes. 

The most likely group of developers to adopt automated security approaches are key decision-makers and team leads who influence, manage, or set the strategy for their teams’ purchase initiatives (90%). 

This probably indicates that many developers still don’t use automation tools for security. However, it’s important for developers to use the best tools when it comes to the production of secure code.

Security in Early-Stage Software

While more than half of enterprise developers are already shifting left, less experienced developers are still behind. Automation appears to be core to the shift-left approach, with two-thirds of developers using automated security tools. 

Nevertheless, automation is not favoured by developers who wish to acquire more experience. This highlights a need for balancing the need for learning with the importance of using the best security tools available.The organisations that are set up to go that way are very likely to reap the fruit of shift-left security.  

Categories
Community Tips

Protecting APIs by Merging Tools and Security Best Practices

protecting APIs

Rapid uptake in adoption by industries ranging from banking to retail to autonomous vehicles of customer- and partner-facing and internal application programming interfaces (APIs) to drive internet traffic has resulted in an equally rapid growth in endpoint attacks – more than 11 billion over just 18 months according to a report from edge computing security leader Akamai. It makes sense that they are more vulnerable to threats from malicious actors, given API endpoints’ similarity to internet-facing web servers, and their role as pipelines between divergent platforms.

For DevSecOps teams, protecting APIs is a top priority; they are vital to mobile, SaaS, and web applications and paramount to a healthy software development lifecycle. API security is also a natural extension of DevSecOps’ push to break down silos between development, security, and operations and move toward automation and design that integrates security as a shared responsibility. 

Thus, it is time to view API security not as an external bottleneck, but as a part of a stable long-term strategy. This can be achieved by altering company attitudes and investing in API tools that facilitate testing, enforce governance standards, and automate recurring security tasks.

Adopt an API-as-a-Product Strategy

A primary reason digital transformation efforts have failed for many brands is because they do not see APIs adding value. As such, they’ve lost track of the potential return on investment (ROI) APIs can deliver. When APIs are not viewed as assets or value-generating, they aren’t subject to the appropriate level of protection or security performance oversight. In fact, Akamai’s report highlighted the fact that many enterprises relegate API security checks to the end of the lifecycle and rely on traditional network security solutions which aren’t designed to protect against the attacks to which APIs are subject.

This is starting to change, however, as API-as-a-Product strategies gain traction within the developer community. There is a notable shift away from delivering project features based on budgets and deadlines to holistically examining APIs as products and assessing their capabilities. Further, as the concept of monetizing APIs gains prominence, their protection becomes a higher priority at the outset, with organizations more inclined to adopt a human-centered design approach. 

What this means is moving API regression tests to the forefront rather than treating them as an afterthought. It means adopting a design-first approach – wherein everyone on the team speaks the same language and every tool is able to leverage the same design – from the outset with the help of an API management platform. This will also help ensure that APIs are built on established authentication and authorization mechanisms such OAuth 2.0, which is the industry-standard protocol for authorization, and OpenID Connect.

API testing tools are critical for protecting something upon which most services in use daily rely. These tools let developers see if an API is reacting adequately to unexpected inputs or possible security attacks. They show immediately if an application is running with optimized functionality, reliability, and security.

Whether it is running user authentication, parameter tampering, unhandled HTTP, or fuzz testing, it is imperative to test an API contract to ensure that services can communicate and that the data they share is consistent with a specified set of rules or standards. Further, there are many solutions in the API testing market, including cross-cloud API testing software, software that supports asynchronous testing and continuous integration/continuous deployment (CI/CD) integrations, and end-to-end testing – as well as solutions that support various formats eliminating the need for developers to learn new languages. 

Continuous testing is essential across the DevSecOps pipeline, as is robust test coverage based on API contracts that have been designed and approved. Plus, by chaining together complex API transactions and workflows, cases can be tested on-demand using continuous delivery or CI/CD to reduce downtime. 

Security in 360-degree Lifecycle Management

While API security considerations have typically been an afterthought to ever-increasing business demands, the reality is that no enterprise can afford for software security checks to be the last stage of an API lifecycle. Rather, security must be part of a 360-degree API lifecycle management strategy. It should be incorporated into every level, from planning and design to developing, testing, and release management – all the way out to deprecation.

Developers must also have oversight throughout the entire API lifecycle – which is where an API management platform comes into play. A dedicated platform can provide workflow visualizers that show an API’s complete lifecycle in a single view with issue alerts, which helps accelerate production using CI/CD in the DevSecOps pipeline to build trusted artifacts and more rapid iterations, thereby guaranteeing a security-first mindset. 

API tools also allow perimeter scans, which enable the discovery and inventory of APIs and allow for easy breakdowns for DevSecOps teams to work with. The best platforms will leverage a command line interface (CLI) – a unified tool for managing and controlling multiple services from the command line or with automation through scripts – to make APIs more easily discoverable. The team can easily determine where and how many APIs are deployed; a level of visibility that is mandatory for enterprises. 

Tools for Success

In short, an API team is only as successful as the set of tools at its disposal.

API security best practices are no mystery to seasoned security professionals – and they start with establishing solid API security policies through an API management platform. 

Finally, a collaborative approach to API governance – in line with the DevSecOps mission to eliminate siloes – is imperative for any organization’s security. 

About APIWizAPIwiz is a low-code, API automation platform allowing developers to build and release reliable APIs quickly. With APIwiz, API teams have complete control, visibility, and predictability over their entire API program, allowing organizations to stay open and connected.

Categories
Languages

App Security 101: A list of top 10 vulnerabilities and how to avoid them

App security 101

App development is becoming more and more popular, as web and software developers are migrating to the mobile industry. Apps have become a part of mainstream culture and entered our everyday lives – at increasing levels. The app economy is comprised of approximately 2 million apps and is expected to continue growing in the years to come.

Secure development on mobile applications, however, has not shown the same level of growth or maturity. As an Information Security firm, we’ve seen quite a few apps suffer from vulnerabilities that are linked to development bad practices, mainly due to lack of awareness. Secure development guidelines do exist in the community, while organisations like OWASP have accumulated a lot of experience in the field and are now offering much of this knowledge for free. In this article we’ll sum up the best practices and show you the best ways to build secure apps. We’ll concentrate on OWASP top 10 (and similar) vulnerabilities, as these are the most common ones found in mobile apps.

So, let’s go through the list of the top 10 mobile app vulnerabilities and how to avoid them.

1. Insecure Data Storage:

This vulnerability occurs because information that is considered confidential is not stored in the device in a secure manner. You shouldn’t assume that the devices themselves are safe. Devices can be stolen and/or tampered with, and the confidential data contained in them may be stolen. Also, you shouldn’t assume that users will protect themselves against this possibility. In order to avoid this vulnerability, the best practices are:

  • Never store credentials on the device itself
  • Sensitive information such as user authentication credentials should only be stored in the device’s keychain, using the necessary API
  • All authentication should be done through HTTPS (updated)

Specific guidelines for iOS developers:

  • You could avoid using iOS Encryption Libraries such as Commoncrypto
  • You should encrypt SQLite databases with SQLcipher
  • You might want to avoid NSUserDefaults, as well as plists in general
  • Keep in mind that the NSManagedObjects will be stored in an unencrypted database

For Android devs:

  • You should use the SD Card Storage the javax.crypto.
  • You can use the enterprise Android administration API to force encryption for local files by utilizing “setStorageEncryption”

2. Weak Server Side Controls

You should implement most controls against input attacks on the server side of the application. Nevertheless, app design should include input validation checks and controls, in order to reduce the load of work to be done by the server. Therefore, you could ensure that both the server side and the mobile client development security requirements include at minimum:

  • Input validation. You can use this kind of data validation in order to detect, and therefore prevent, unauthorized input before it gets processed by the app itself
  • Canonicalization. Data input in the app should be converted to its canonical (simplest) form in order to be processed by it
  • White lists on allowable data. The white list validation approach allows only specific types of data as input to the application; everything else that’s not included in this list, is not authorized.
  • Output encoding. You should encode the output that is presented to the user in order to prevent different kinds of attacks (e.g. XSS[1][2], format string attacks).

3. Insufficient Transport Layer Protection:

You should enforce the TLS/SSL encryption with strong algorithms between communications. A common development mistake is unencrypted connections from the application to 3d party companies. You should program your apps to display any certificate error or warning messages, so that the user is informed of the quality of the encrypted connection.

For iOS developers:

  • Use the CFNetwork API that utilizes NSStreamSocketSecurityLevelSSLv3 / TLSv1.2.
  • You should use,the setAllowsAnyHTTPSCertificate parameter to prohibit accepting all certificates

For Android developers:

  • You should set the AllowAllHostnameVerifier parameter to prohibit accepting all certificates

4. Client Side Injection

This category is comprised of a wide variety of input attacks against the application itself. General best practices for mitigation of client side injection vulnerabilities include the input validation of the application entry points, on the server side.

For iOS developers:

  • You should consider using parameterized queries (e.g. ? instead of %@, libXML2 instead of NSXMLParser)
  • In addition, you should avoid functions that are known to be prone to code vulnerabilities, such as strcat, strcpy, etc.

Android developers:

  • You should use parameterized queries
  • You should disable Javascript and plugin support for Webviews
  • You should also disable file system access for Webviews
  • You might consider using input validated intent filters between Activities

5. Poor Authorization and Authentication

These vulnerabilities are controlled mostly on the server side. The best practices that you should follow are the same with web applications. In addition to these rules, specifically for app development, device identifiers should be avoided (UDID, IPs, MAC Addresses, IMEI) since devices can be stolen and tampered with. Finally, out-of-band authentication tokens should not be sent to the same device.

6. Improper Session Handling

Although session handling mechanisms are mainly applied at the server side of the applications, secure session management practices can be applied at the devices themselves. As with the Authorization and Authentication, you should apply the web application Best Practices for session handling. Same as with authorisation and authentication best practices, device identifiers should be avoided here as well and you should implement safe mechanisms to revoke session on lost/stolen devices. Finally, the Confidentiality and Integrity of session tokens should be protected at all times (secure transmission via SSL/TLS connections, etc).

7. Security Decisions Via Untrusted Inputs

While these issues mainly affect Android-based applications, there has been precedent for iOS apps too. In general, the Best Practices that you should follow are the same with the web application ones. Specifically, input validation, output escaping, authorization controls and canonicalization should be carefully examined. Also, you should exercise extra caution when validating and accepting URL schemes.

8. Side Channel Data Leakage

This category involves data exchange that usually enhances app performance (e.g.: keystroke logging, web caches). As with Insecure Data Storage, you should build your app under the assumption that the device might be stolen. All side channels and 3rd party libraries included should be identified and enumerated for any possible data leakage that might occur. The application should be dynamically tested in order to verify that it doesn’t leak data during runtime.

iOS developers:

  • You might consider disabling screenshots, along with cut-and-paste buffers. It is also recommended to disable keystroke logging from within the application.

9. Broken Cryptography

Crypto-keys should never be hard-coded in any construct (plaintext, property files, compiled binaries) and should be controlled at the server side.

10. Sensitive Information Disclosure

Different kinds of information may be considered sensitive in an app, as application logic/business purposes define that. You should keep mind that apps can be reverse-engineered and information like this might be exposed. The best practices in this case suggest avoiding storing private data inside the device; unless absolutely necessary.

The vulnerabilities presented here are not an exhaustive list – they’re just the tip of the iceberg! During the past year, we’ve witnessed numerous attacks against apps by direct code exploitation that usually leads to the device becoming compromised. We’ve also seen attacks that leverage various app weaknesses in order to hijack legitimate user sessions and steal information and money.

Since the app market is constantly growing, we expect to see an increase in the number of attacks against mobile devices themselves. So, if you want to keep up with the times, [tweetable]you should build your next apps with app security in mind[/tweetable].

For more insights, get in touch.

– George

George Karagiannidis is a Senior Information Security Consultant at TwelveSec (TwelveSec.com). George is a seasoned pen-tester, having accumulated a wealth of experience from performing, as well as leading, Information Security projects that range from System/Network/Web/Mobile Application Penetration Tests to Reverse Engineering, Security Design and Architecture of critical Information Systems, and Information Security Management System (ISMS) implementation.

Categories
Business Tips

The Costs of App Security

app security costs

The security features of an app are often ignored in the rush to get a new product to market. We naturally tend to focus more on what an app should do, rather than what it shouldn’t. Making sure that an app doesn’t have security issues is a difficult and potentially expensive process. Lately there is evidence that developers are trying at least to face app security costs issues. A recent post from our partners in DZone shows exactly this.

There are no automated tests to ensure user data hasn’t been left vulnerable. This goes for unencrypted passwords as well. Typically this requires a manual audit of the code and some form of penetration testing, with a skilled developer attempting to compromise the app. However, the costs of implementing security features and adding security testing to your development process are much smaller than the potential costs of a major security breach.

Problems with payments

For some types of app the consequences of this are more obvious. There are even standards in place to try to ensure a minimum level of security. For instance, any application which handles payment card details needs to process that data securely as specified by the Payment Cards Industry. However, PCI standards compliance is only audited for large merchants. Smaller merchants self-certify compliance.

If an app or service for a small merchant was compromised, resulting in abuse of payment card data, then any non-compliance discovered could result in significant fines or even liability for any fraudulent payments. Merchants who add interfaces to their existing payments infrastructure to support mobile apps need to be particularly careful. New attacks can be made possible when the payment authorisation occurs on a native mobile client, rather than a website.

Even for apps selling digital goods via in-app purchase there are still payment security issues to consider. Of course stakes are nowhere near as large. However, attackers can still impersonate the official store provider servers and simulate in-app purchases without any genuine payment.

Apple’s system was compromised in this way last summer. Another hack was reported for payments on Google Play just before Christmas. There is no link to this because, although it was only for rooted devices, we’re not aware of a fix in place yet. (Indeed it may even be a scam to get users to install malware).

Losing data can cost you even more

For enterprise app developers, being associated with a major security breach could mean the end of your business.

A harmful loss of data for a client could send valuable market data go to the competition, or even key employees. You would lose trust (and business)! If the breach is sufficiently public, you could lose the trust of all potential future clients as well.

The larger a company the more vital it is that they implement good security practices.

For consumer apps, leaking user data to attackers has direct costs. Firstly, in terms of service downtime whilst fixing security holes (usually in a hurry with the aid of expensive experts), notifying those affected and possible compensation. Secondly, there are serious indirect costs in terms of lost trust and users. Again here, the larger the user base, the more attractive the app is to attackers and the more serious any breach.

Invest in app security appropriately

Investments in security need to be proportional to the risks. How many users are involved and the value of data stored should determine the level of effort required to ensure that data is safe.

Not knowing about the security implications of your application is somewhat like driving without insurance.

Everything is fine until the unthinkable happens. Then it’s likely that lots of innocent people suffer and you get into a lot of trouble.

The technical details of app security are beyond the scope of this post. However, we have prepared a list of top 10 vulnerabilities and how to avoid them. Read on if your app deals with any user data or payments.