How Secure is your API?

By Sairam Bollapragada & Sandeep Mehta

Technology will keep evolving and the existing platforms will keep transforming to make our solutioning richer with far more reaching impacts. API is the evolving technology glue which is promising strategic and much higher complex communications between the applications with many of the technologists vouching for them.

Just to strengthen the case and context here, Ovum Survey mentions that 30% of APIs are designed without the inputs from the infosec teams, 27% proceed with the development without security teams weighing the same, while 53% of IT/security professionals feel security teams should be responsible and 47% feel it should be developers. Of the API platforms used by companies (borrowed or in-house developer), only 22% had protections from 4 critical attack parameters – developer errors, web/mobile API hijack, automated scraping or malicious usage). 45% of the API Management platforms are infested by the rate limiting features. The list and arguments go on.

What are the threats to an API Platform

There are some jot-it-down parameters which should be hard-looked at whenever an API based solution design becomes a suspect.  Let us look at them and ponder on detections or workarounds.

  1. Unprotected APIs: API’s should have prioritized insulation built around them. REST, SOAP,  make access strictly controlled as back-end systems lack access control, management and monitoring. Exposed APIs must be dynamically scanned to ensure system exposures to unprotected assets via APIs are identified whenever there are requests made for access through the API layers.
  2. Hack-in Attempts: The attackers have high sustenance to break into the systems with spectrum of persisting techniques. Effective usage of rate-limiting services via API gateways to choke access requests and detect break-in patterns will help, upfront security testing and policy designs to block out users with patterns of malicious failed break-in attempts will be good strategy.
  3. Injections: High Impact attacking techniques like the SQL injections can become a most serious security failure with all your information compromised. One of them could be for output data written back to the API caller, is the source of data authentic and how is the encryption taking place? What is the extent of the data user control? Etc. This being a very vulnerable part, tools like SQP Map for testing the SQL injection, Burp Site for the same or even cross-site scripting are useful to prevent such threats.
  4. Strong Authentication!: APIs are designed to be exposed for external usage and hence every caller should be authenticated. The authentication cycle must be completely audited and checked from request initiation to termination using approved authentication standards. Application level testing to ascertain weakness of API approved authentication protocols would greatly assure validation of calling applications token.
  5. Session depravity: Not knowing who is the caller of API when the tokens are corrupted or cannot be authenticated will deem it impossible for API servers to differentiate between well-intended and ill-intended access. Tokens when tampered or replayed with altered privileges can create such a scenarios. Token-protection schemes like hashing and ensuring tokens are fresh using verified timestamp will help. A test suite developed to check token tampering is identified/tracked, or only accepted from authorized sources is mandated.
  6. TLS/SSL Protections: TLS/SSL Protection makes sure that data transferred between users/sites or between two systems becomes impossible to read. It uses  encryption algorithms to scramble data in transit.
  7. Trusted V/s Trustworthy: A trusted computer system is a system that is trusted to perform security- or safety-critical operations, a trustworthy system is a system which has already been trusted and secured using encryption methodologies.
  8. API Right Usage: An API should be used for what it is designed for. Many times the implementation on the API platform exceeds the functionality available on the platform. This exposes the whole platform to new set of risks. The limitations of an API platform have to be strongly kept into consideration whenever it is being evaluated for any solution. Also one fact to be kept in mind is that the API should peacefully Coexist
  9. Poor Code: Poor Code on an API exposes the platform to lot of vulnerability, examples of Poor Coding on API are not implementing certificate based authentication and not restricting IP addresses to filter only from known sources. This will expose the API platform to all external IP’s and anyone with basic skills can access the API and perform their operations.

Finally, whenever an API is being designed or being evaluated for usage, the base security parameters have to be sufficiently considered and evaluated. The evaluation or design of the product should always keep enough room to extend security features as and when required. There should also be enough facilities to implement remedial measures or alerts which will alert the users whenever there is any security threat or breach of the API.

Advertisements

IoT Security is everybody’s business!! – Part 1

By Sairam Bollapragada

With the Digital wave, the structure of the IT organizations, especially those racing to embrace new technologies and IoT is poised for a paradigm shift. Every brilliant side of technological revolution comes with a darker patch as well. With so much of data slated to being generated via connected devices, the Cyber Security can no longer be the forte of IT folks ONLY.

While technology brings in convenience, it also comes at a cost (read flip side).

In the recent past in India, we have started seeing mobile wallets increasingly being used for payments and other financial transactions to another device or account. The connected wallets also create opportunities for hackers to break in and creatively lay their hands on the information pertaining to transactions, account details, the payee details, their numbers, the payment patterns, sources of funds, and many such confidential data which one would not like to divulge.

Cyber security, will don a new hat with the advent of new technology and devices working in tandem. Trying to stop break-ins will need a lot more intelligence and smart techniques to be devised. The provisioning of security to these mushrooming applications and connected devices will need to be really understood well so that people know they are secure while transacting with gates to personal data. The approach itself requires comprehensive techniques.

The mobile channels will provision more incentives with increase in volumes of both devices and transactions. The global reach of the mobiles have opened standard techniques for the hackers across the global hacking communities. Ubiquity and connectivity are vulnerable and enables folks to get to mobile devices. The incentives are more for mobiles which use financial transactions, undoubtedly. It may not be hard for hackers to know which user uses which number to carry out which financial transactions.

The richer the features of the mobile, the more it becomes a target for the hackers.  The concern about the privacy invasion by advertisers is rising steeply with these smarter devices. In 2010-11 Wall Street conducted a test for 101 Android/iOS applications and found that more than half sent device information, 47 shared location data, and 5% users –  personal information to advertisers without the consent of the users.

More than 1000 malware target mobile devices globally. An instance of worm attack can infect mobiles rapidly to the tune of millions of handsets.  As mobiles are getting more advanced so are the worms accomplishing more sophistication – raising their quality of attack as well.  As technology carriers are improving the device capability, the blue-tooth and Wi-Fi is also becoming airborne contaminators. Some viruses dial international numbers while the subscriber is sleeping.

The mobile computing increases the data loss as well. With the connected devices expected to transmit data across applications and other devices, the hackers would try means and ways to create opportunities in the chaos. Mobile banking has also brought in rogue applications which are smartly working their way to gather financial information from devices through even legitimate applications topped with these malware at app stores.

Over all this, it is said that more than 37% of the service providers do not have any threat intelligence programs.

Impacting Scenarios

As hackers take control of the connected devices, the very capability for which the IoT was brought in (efficiency, productivity, ease, etc) will be compromised.  It is scary to even think what if the folks are unable to stop machines, controlled by connected devices for convenience- large ones at that. IT security itself will not stand ground here.  The extended knowledge across applied industrial controls and production processes would become mandatory to put the checks and balances in place. (What if one is not able to stop a blast furnace in steel plants?…)

Water Management:  Anything which is scarce and essential comes under the cloud of threat and catches attention for disruptive opportunities. Water management through connected devices is becoming a lucrative offering from many vendors ensuring appropriate water quality, controlled water supply, water treatment, metering and other features. Water consumption, like electricity is also vulnerable where automatic vaults and control mechanisms for pressure and flow are devised to be controlled through technology. A loss of control would create wastage of water across and lead to a water crisis.

Patients Health Records (PHR)

The PHRs of patients are too personal a data to be privy to. These personal health records reveal several confidential parameters of personal health profile of an individual with historic ailments, health issues in the recent past, blood group info, and many more data which can lead to people either playing with or destroying the data for obvious reasons or holding the same for ransom. Very dangerous but true, not because we need to be scared, but the awareness of such a threat is missing till the first casualty occurs.

The Nuclear plants, used for positive reasons, like generating power can be a huge source of risk – if they were to lose hold over the control process of nuclear reactors.  If IoT based controllers were deployed in these plants for the purpose of analytics and other accompanying research advantages, there should be exhaustive sets of checks and audits built in – plus multiple approvals at multiple governance decision points to ensure disasters would be at least minimized.

Likewise, hacking connected or smart cars can lead to road disasters.  This includes the hacking of smart traffic management – feature of smart cities. Insurance transactions can be blocked and claims disabled or diverted, where insurance segments are moving from statistics to individual fact-based policies.

Cloud is another source of vulnerability. The plethora of data being stored on cloud will require tighter secured solutions, and hence the cloud data security will only become more crucial.

It is said that M2M communications will themselves generate about $900 billion in revenues by 2020.

Dependency on the connected devices for various aspects of the futuristic work-style like improved real-time decision making, better design of solutions, reliability on the so-generated data analytics (what about data quality?), driving future product conceptualization, fleet management,  and many others could be a challenge if the systems malfunction due to malware or cyber-attacks.

The above are potential scenarios where the flip side of technology, if misused, can create disasters and can cause unimaginable disruption. However, it is not too late to create a strategic security blueprint and get the awareness levels in the public embracing these newer emerging solutions in future.

We will discuss the potential next steps on what we should do, what the state agencies should do and what the general users should know in the sequel to this blog shortly. Till then happy reading….