Search This Blog

Loading...

Tuesday, 12 July 2016

Turmoil in the CASB market - 2016 the year of Big Business Acceptance

In April of last year, I wrote a technical comparison of the various players in the CASB (Cloud Access Security Broker) space, and had such incredible response and discussion, that I felt I had to provide an update this year. Should be easy, right?  WRONG!

(Read the above article if you are new to CASB and want an understanding of the space)


The CASB market has seen a lot of turmoil over the past year, in the form of mergers and acquisitions.  Early on we all thought Cisco was going to acquire Elastica as they had become quite cozy, but in a screeching left turn, BlueCoat came from the sidelines, and snapped Elastica up. The surprise here is that earlier in June of 2015, BlueCoat had just acquired CASB player Perspecsys.  Fast forward to June of this year, when BlueCoat announced their intent to IPO, then only days later agrees to be acquired by Symantec for $4.65B.  Whew...

In a similar roller coaster,  Adallom cozies up with HP in April 2015, only to get bought by Microsoft in September.  Then just last week, Cisco, not to be left out of the CASB market announced their intent to acquire Cloudlock.

Also in recent news, Skyhigh Networks obtained a patent to use reverse proxies for cloud access security broker services, and Netskope obtains a patent for routing client traffic securely to Cloud Services. I'm not sure how this is going to change how the others model their business.


So to recap...

Last year, in the CASB space, we had: 
Adallom, BitGlass, Ciphercloud, Cloudlock, Elastica, Imperva, Netskope, Perspecsys, and SkyHigh

This year, the landscape looks to be:
Bitglass, BlueCoatCiphercloudImperva, Microsoft, Netskope, and SkyHigh.






I closed last year's report with the statement:
"Although the CASB market space is still in it's infancy, the main players have done a good job defining - and meeting - most of the requirements of an off-premise security service. I'm interested to see what happens to this space over the next three years.   My money is on convergence of CASB, SSO, and Mobile Security providers."
I still hold to this: Cloud SSO is what gives CASB the ability to understand context, and Mobile Security (Device Security, Application Security, Data Security)  is required to manage endpoints outside of the corporate perimeter.  Yet I'm not seeing those acquisitions as yet.


I think it's going to be an interesting challenge to to update last year's report. Stay tuned. 


If you are a current CASB provider that I have missed here, and want to be included in the upcoming report, please comment below, and I will contact you for validation.



CASB References:

Gartner: The Growing Importance of Cloud Access Security Brokers
http://www.computerweekly.com/news/2240223323/Cloud-access-brokers-top-security-technology-says-Gartner
Gartner: Emerging Technology Analysis: Cloud Access Security Brokers
http://www.ciphercloud.com/2014/09/30/public-cloud-security-demands-cloud-access-security-broker-casb/
https://www.netskope.com
https://www.elastica.net/
Bitglass: The Definitive Guide to Cloud Access Security Brokers
CipherCloud looks to stay at the head of the cloud security class 
Ciphercloud: 10 Minute Guide to Cloud Encryption Gateways
Ciphercloud: Cloud Adoption & Risk Report in North America & Europe – 2014 Trends

NetworkWorld: How the cloud is changing the security game
Adallom: The Case For A Cloud Access Security Broker
Adallom: Cloud Risk Report Nov 2014
Check Point Capsule and Adallom Integration 
HP - Adallom: Proven Cloud Access Security Protection Platform 
Adallom : to Offer Comprehensive Cloud Security Solution for Businesses With HP 
PingOne - Skyhigh: PingOne & Skyhigh Cloud Security Manager
ManagedMethods: Role of Enterprise Cloud Access Security Broker
Standing at the Crossroads: Employee Use of Cloud Storage. 
Cloud Computing: Security Threats and Tools 
SC Magazine: Most cloud applications in use are not sanctioned  

http://www.businesscloudnews.com/2015/04/22/cisco-elastica-join-forces-on-cloud-security-monitoring/
https://www.elastica.net/2015/04/cisco-to-offer-elastica-shadow-it-and-casb-solution-to-enterprises/
Elastica And Cisco Move To Product Integration Of Cloud Web Security And Elastica CloudSOC
Blue Coat Acquires Perspecsys to Effectively Make Public Cloud Applications Private
Blue Coat acquires Elastica in $280 million CASB deal
Fortune: Bain Wants To Take Cybersecurity Firm Public Despite Weak IPO Market
Fortune: Blue Coat Abandons IPO Plans, Sells To Symantec for $4.65 Billion

Cloud security vendor Adallom secures $30m from HP, Rembrandt Venture Partners
Hewlett Packard Ventures and Adallom: Partnering to Protect the Enterprise Cloud
Microsoft acquires Adallom to advance identity and security in the cloud

Cisco Announces Intent to Acquire CloudLock for $293M

Stratokey: Cloud Access Security Broker (CASB)

Netskope awarded patent for cloud visibility, governance

Big Tech’s Entry into the CASB Market Is Evolutionary
Microsoft acquires Adallom to advance identity and security in the cloud

http://searchcloudsecurity.techtarget.com/news/4500253289/CASB-roundup-Microsoft-confirms-Adallom-buy-Netskope-raises-75M
https://www.skyhighnetworks.com/cloud-security-blog/what-the-adallom-acquisition-means-for-the-casb-market/

http://searchcloudsecurity.techtarget.com/answer/How-can-a-reverse-proxy-mode-improve-cloud-security

Gartner: Market Guide for Cloud Access Security Brokers
Gartner: How to Evaluate and Operate a Cloud Access Security Broker


Tuesday, 21 June 2016

Threat Modeling a Mobile Application

The purpose of this article is to provide security guidance in the development of mobile applications.  The following application threat-model (ATM) is an example, created to help developers identify potential threats that a malicious attacker could use to exploit a custom developed Mobile Application.

This threat model
 example is based on Industry Best Practices and observations across the Mobile Application Development space, and is not based upon any one particular mobile application.  The scenario presented here assumes an application in the Banking and Finance space, but could be any industry.


From a Security and Privacy perspective, a mobile application must:

  • Prevent the un-authorized use of web service API associated to the related application
  • Prevent the accessibility of information or operational control of a user’s account
  • Prevent the ability for a third party to gain identification and authentication details
  • Reduce the opportunity or intention of a malicious user from accessing confidential information

Threat Profile:

A "Threat Profile" is the concept of identifying the complete set of security threats that could be used to compromise a given application or system.

The following Business Criteria and assumptions were used when assessing the threat profile for this example Mobile Application:
  • Industry Categorization                        Financial Institution 
  • Organizational Audience                       Business Users 
  • Level of Potential Threat to Audience   Moderate-threat Audience 
  • Degree of Confidential Data                  Moderate 
  • Likelihood of Exploitation                     Low to Moderate 
  • Delivery Platform                                 Mobile devices with Secured Sandboxes 
  • Level of User Interaction                      Minimal 
SANS: Threat Profiling


Threat Agents:

A threat agent categorizes the types of intentional and unintentional users associated to the system. This can include, but does not require, the intended roles of the application.




Stolen Device User: A user who obtained unauthorized access to the device aiming to get hold of the memory related sensitive information belonging to the owner of the device.
  • Access to account information to perform unauthorized transactions 
  • Access to account information to perform transactions from a different account 
  • Attempt to garner information about the banks overall security structure 
  • Denial of service attack against back-end systems based on gathered information

Owner of the Device: A user who has unwittingly installed a malicious application on their phone which gains access to the device application memory.

  • Capturing of credentials associated to the account for use by third party

Common WiFi Network User: This agent is aimed at any adversary intentionally or unintentionally sniffing the WiFi network used by a victim. This agent stumbles upon all the data transmitted by the victim device and may re-use it to launch further attacks.

  • Capturing of credentials associated to the account for use by third party 
  • Ability to perform unauthorized transactions

Key Scenarios:


The following scenarios or activities have been identified as key to the success of the application's security profile:

User Authentication - to gain access to post-sign-on functionality and content on the Mobile application.

Get Portfolio and Rates, and Execute Trades 
- User being presented with the list of transactions associated with specific Rates (Wire Payments, Cross-currency Account Transfers). The User could retrieve, view and accept the rate presented for selected payment. The User could view Beneficiary Details and the Audit History Page of the selected payments. The User could manage Contacts and make phone calls using the Audit History information.


Payment Approvals - User being presented with the list of payments (Wires, Account Transfers, EFT, Bill Payments) that qualify to be approved/released by the user. The User could view payment details and approve/reject selected payment. The User must be re-authenticated as a part of each payment approval operation. The User could view Audit History Page of the selected payments. The User could manage Contacts and make phone calls using the Audit History information.


Accounts Module - User being presented with the list of accounts he is entitled to. The User could add/delete/change order of Favourites Accounts in the list. The User could query and view account balances and transaction history information.


Mobile Application Architectural Elements:

The following items are associated to the application architecture specific to mobile devices. This listing mechanism is intended to provide additional input and consideration into the overall threat model.



1.Carrier Elements
  1. Data
  2. SMS
5.Device
  1. iOS
  2. Android
  3. Blackberry
2. Web Services using RESTFUL agents over SOAP 6.Common applicable hardware components
  1. Wireless Interfaces
  2. USB Ports
3. App Store
  1. Apple App Store
  2. Android Play Store
  3. Blackberry World 
7. Authentication
  1. Token Based
  2. Certificate Based
  3. Keyboard Based
  4. Touchscreen Based
  5. Biometric Based
4.Wireless Interfaces
  1. 802.11
  2. Bluetooth
  3. NFC






























Planned Application Security Mechanisms:

Planned application security mechanisms are technologies and threat-management measures that are included in part of application architecture and design. The model ignores these when defining the potential threats associated to the system but references them as solutions to identified problems.


The following application security mechanisms have been identified as part of application security design:
  • HTTPS secure transportation protocol using TLS 1.2 or above 
  • Two-phase authentication 
  • Input and data validation 
  • Exception handling 
  • Auditing and logging 
  • Minimization of operations

Trust Boundaries:




An organization and its application define a series of perimeter that define different levels of security-oriented trust. The following information defines the trust boundaries associated with systems, sub-systems, and identities.



App Container Boundary
within secure devices including iPhone and BlackBerry
Internet Trust Boundary is the connector between the device and internal banking systems
DMZ Trust Boundary including perimeter firewall where core services are located
Data Center Trust Boundary in which direct hosted systems and services are located.
Data Flows:

Data flow diagrams help document the flow of information across trust boundaries.

Understanding how data is communicated across boundaries help identify potential issues within communication protocols and mechanisms.

The following diagram represents the data flow of the application under investigation



Entry and Exit Points:

Entry Points

Entry points define the positions in your application where a user, cross-component communication or external application supply data and call operations associated to the back-end systems.
  • Mobile Application access to back-end API through JSON services.
  • Unintentional direct access to back-end API through JSON services. 

Exit Points

Exit points are relationships to entry points and define the positions in which data is sent to the client. Exit points are prioritized to identify where information is transmitted in a trusted manner but the source is untrusted.

Potential Attack Tree:

An attack tree is a hierarchal diagram (or outline) that represents the attacks a malicious individual might perform against the application. This information is based on the development of an attack profile organized around the industry and type of threats associated to your application and end users


Gain authentication information to be used in other applications, systems or services 
  • Authentication and access control attacks to determine applied security measure 
  • Determine the depth of breach and fraud preventive controls 
  • Access account to be used on other systems

Monitoring of transactions to record communication patterns

  • Obtain confidential information about the system 
  • Gain details on how transactions are processed in the system 
  • Discovery of weaknesses associated to the back-end system

General financial fraud

  • Perform unauthorized financial transactions to correct associated bank accounts 
  • Determine clients and size of transactions for social engineering attempts

Data Collection by running application in a non-trusted environment (jail-broken)

  • Ability to access the application in a jail-broken device or development platform 
  • Ability to apply memory forensics on the application at runtime to gain confidential information 
  • Ability to apply memory forensics on the application to determine run-time details

Unmanaged JSON attacks over encrypted or unencrypted channels

  • Ability to perform data theft through cross-site references 
  • Ability to perform a denial of service attack using cross-site references

Threat Tree:

A Threat Tree describes specific threats that can be applied to the application. Information in this section is defined in a threat-based tree for reference and specific descriptive afterwards. Please note that a single threat can be related to one or more common or uncommon vulnerabilities.  
  • Authentication / Authorization 
  • Input and Data Validation 
  • Relying exclusively on client-side validation 
  • Writing data you did not validate out to trusted source 
  • Using input you did not validate to generate SQL queries 
  • Configuration Management 
  • Sensitive Data 
  • Basic Man-in-the-Middle Attack 
  • Request Forgery 
  • Session Management / Cryptography 
  • Parameter Manipulation 
  • Failing to validate all input parameters. 
  • Exception Management 
  • Failing to validate all input parameters 
  • Audit and Logging 
  • Missing Security Auditing Features 
  • Unsecured Audit Logs 
  • Mobile Specific Threats 
  • Method aimed to read the local application memory 
  • Malware on the device 
  • Transactions performed from non-localized location


Rating Potential Threats:

Relying Exclusively on Client Side Validation:

Threat Description By relying on client-side validation the system allows for exposure of the back-end services through compromised client systems as well as communication protocols. This issue includes common assaults results including “Writing data you did not validate out to trusted source” and “Using input you did not validate to generate SQL queries”
Category Input and Data Validation
Threat Target
  1. Capturing of credentials associated to the account for use by third party.
  2. Ability to perform unauthorized transactions.
  3. Denial of service attack against back-end systems
  4. Attempt to garner information about the banks overall security structure
  5. Access to account information to perform unauthorized transactions
Risk High
Attack Techniques A malicious attacker compromises the mobile application by installing it on a jail-broken device or reviews data communication though a proxy service. Unintended information (pre or post authentication) is sent through the communication protocol to the back end server containing injection data or unintentional information.
Countermeasures
  1. Use of SSL with trusted certificates to encrypt communication.
  2. Validation of data at all trust boundaries to manage tampered data.



Basic Man-In-The-Middle Attack:

Threat Description User is able to monitor the data being communicated from the mobile application to the associated server in order to determine the URL, formats and identity of back-end services for direct access to the service.
Category Sensitive Data
Threat Target
  1. Capturing of credentials associated to the account for use by third party.
  2. Attempt to garner information about the banks overall security structure
  3. Access to account information to perform unauthorized transactions
Risk Medium
Attack Techniques Use of data monitoring tools including BURP Scanner or WireShark as proxies to view data being transmitted from the mobile application to the server.
Countermeasures
  1. Use of SSL with trusted certificates to encrypt communication.
  2. Validation of data at all trust boundaries to manage tampered data.
  3. Source checking of communication using CSRF-token based concepts



Request Forgery:

Threat Description An unauthenticated user sends requests through HTTP protocols in an attempt to (1)subvert authentication mechanisms, (2) perform destructive activities against a system, (3) gain information around exception handling mechanisms, or to (4) garner information about the system and its transactions
Category Sensitive Data
Threat Target
  1. Capturing of credentials associated to the account for use by third party.
  2. Ability to perform unauthorized transactions.
Risk Medium
Attack Techniques Use of data monitoring tools including BURP Scanner or WireShark as proxies to view data being transmitted from the mobile application to the server.
Countermeasures
Use of a secure token (similar to a CSRF token) to acknowledge authorized transactions to the system and to take appropriate measures including alerts and logging when un-authorized transactions are performed. The same mechanism used in a CSRF token can be used in this circumstance.

Missing Security Audit Features:

Threat Description Attacks by an unauthorized user is not properly documented by the system reducing the opportunity for breach attempts to be discovered, hindered or prevented. From a security practice audits and logs should be applied across application layers and servers.
Category Auditing and Logging
Threat Target
  1. Denial of service attack against back-end systems
  2. Ability to perform unauthorized transactions
  3. Anti-forensic measures
Risk Low
Attack Techniques This threat does not have a direct attack; it represents an inability to detect and manage the assault in the case of a breach.
Countermeasures
  1. Log all security oriented transactions to a “security log file”
  2. Recognize unusual number of requests to any series of accounts
  3. Critical transaction attempts are logged for fraud controls

Unsecured Audit Logs:

Threat Description Once a breach has occurred, a malicious attack will attempt to alter or remove log files that demonstrate their attempts. This is a common step for an attacker in a breach to reduce the chance of success for a forensic investigation.
Category Auditing and Logging
Threat Target
  1. Denial of service attack against back-end systems
  2. Ability to perform unauthorized transactions
  3. Anti-forensic measures
Risk Low
Attack Techniques Upon a system breach the attacker will modify or delete the associated log files so evidence of their activities are removed.
Countermeasures
  1. Audit files are located in a protected directory for with access controls
  2. Modification, viewing and back-up of log files have specific user controls
  3. Use of frequent back-ups for security files to single-direction systems

Method to Read Local Application Memory:

Threat DescriptionIn this attack methodology, the data targeted is application specific memory and the method used is memory based analysis. The attacker steals sensitive data like passwords, userid, user account information which is stored in the application memory by reading the device memory.
CategoryMobile Specific Threats
Threat Target
  1. Access to account information to perform unauthorized transactions 
  2. Attempt to garner information about the banks overall security structure 
  3. Capturing of credentials associated to the account for use by third party
RiskMedium
Attack TechniquesThrough development or forensic tools on the device or using a developer workstation, the system and application memory is reviewed while the application is running to determine how information is stored, communicated and its residual nature.
Countermeasures
  1. General memory management techniques for the individual platform 
  2. Nullifying variables with confidential data as soon as they are used 
  3. Minimal storage of confidential data while in memory 
  4. The storage of confidential data in memory in an encrypted format

Malware on the Device:

Threat DescriptionAny program / mobile application which performs suspicious or unauthorized activity. It can be an application, which is copying real-time data from the user’s device and transmitting it to any server. This type of program executes parallel to all the processes running in the background and stays alive performing malicious activity all the time. E.g. Olympics App which stole text messages and browsing history. On a Jail-broken phone this can include access to the applications memory, buffer overflow threats
CategoryMobile Specific Threats
Threat Target
  1. Access to account information to perform unauthorized transactions 
  2. Attempt to garner information about the banks overall security structure 
  3. Capturing of credentials associated to the account for use by third party
RiskLow
Attack TechniquesOften malware is installed on a device through unintentional means where the malware itself is a Trojan or worm that is embedded in a useful application. Once installed the application slowly consumes and analyzes other applications in the device. Malware is most often found on Jail-broken phones in which non-App store related applications have been installed. Malware is often not a targeted attack but attack by drawing.
Countermeasures
  1. The use of managed devices with a white-listed applications
  2. Encrypt Data at Rest on the device
  3. Encrypt Data in Transit 

Transaction Performed from Non-Localized Location:

Threat DescriptionAn unauthorized user attempts to perform a transaction from a distributed location with the goal of applying a fraudulent action. This may include a single or multiple financial transactions
CategoryMobile Specific Threats
Threat Target
  1. Access to account information to perform unauthorized transactions 
  2. Attempt to garner information about the banks overall security structure 
  3. Denial of service attack against back-end systems
RiskHigh
Attack TechniquesAn individual using a stolen device or perform a transaction from a distributed location (uncharacteristic of the user) is able to perform multiple transactions
Countermeasures
  1. Use of geo-location to monitor the location of transactions for a user 
  2. The mapping of geo-location to potential fraudulent locations 
  3. The validation of transactions when listed geo-locations are not used

Threat Risk Rating:

Threats are rated into three categories (Low, Medium and High) based on their DREAD rating. The individual elements associated to this rating are as follows:
  • Damage potential: How great is the damage if the vulnerability is exploited?
  • Reproducibility: How easy is it to reproduce the attack?
  • Exploitability: How easy is it to launch an attack?
  • Affected users: As a rough percentage, how many users are affected?
  • Discoverability: How easy is it to find the vulnerability?

Threat
D
R
E
A
D
Total
Rating
Basic Man-in-the-Middle Attack
2
3
3
1
2
11
Medium
Request Forgery
2
3
3
1
2
11
Medium
Relying exclusively on client-side validation
3
3
3
1
3
13
High
Missing Security Audit Function
1
1
1
1
1
5
Low
Unsecured Audit Log
1
1
1
1
1
5
Low
Method aimed to read the local memory
2
1
2
1
2
8
Medium
Malware on the Device
1
1
1
1
1
5
Low
Malicious App
1
1
1
1
1
5
Low
Transactions from non-localized location
3
3
3
1
2
12
High
Threat
D
R
E
A
D
Total
Rating

References:

Monday, 13 June 2016

Securing the Internet of Things - Developer's Guidance

The "Internet of Things" or "IoT" as it's affectionately known, has become one of the most prevalent buzzwords of 2016.  Almost everything you touch today is somehow associated with it. Everything from smart thermostats, security systems, refrigerators and baby monitors in your home, to fitness bracelets and watches on your wrist, are connected to the Internet now.  From clothing that use coloured LEDs to reflect your mood, to children's educational toys, all have connectivity to "enhance your life experiences".


With the race to bring new products to this evolving market, issues of both Security and Privacy are raised for consumers. At the low end of the spectrum, an attached IoT device could expose your WiFi configuration.  On the high end of the spectrum, your personal banking, and health information could be exposed. 


Depending on who you listen to, the analysts are saying that there will be between 25-30 BILLION Internet connected devices by the year 2020... just a short 4 years from now. (Cisco says 50 Billion!)


http://hpe-enterpriseforward.com/eiu-securing-iot/


Each one of these devices is a potential
Security or Privacy liability.


  • only 33% of organizations believe their IoT products are “highly resilient” against any future cyber security threats,
  • 48% of companies focus on securing their IoT products from the beginning of the product development phase.


http://hpe-enterpriseforward.com/eiu-securing-iot/



In the past year, we have seen:


Cisco: IoT Security Timeline

Who are these "Malicious People" and why do they want to wreak havoc with our Inventions?


IoT devices and systems are typically remote sensors or controls involved in managing a process of some sort. Whether it be collecting weather information for crop management, to sensor data for proper maintenance of an automobile, temperature and humidity information for building climate control, or bio sensors for monitoring a patients health, IoT devices manage a large amount of critical information.  Critical information that could potentially be considered Private and/or Confidential in nature. 

IoT PenguinBot
By the remote nature of these devices, they are also typically designed to be "low cost" and "low energy" battery operated systems.  Function and performance are the critical design success factors, while Security has not played a significant development role to date.  MOST current IoT devices are readily exploitable through several means. 

Oh, and did I mention that most IoT devices are connected (and trusted) in some way to logging, monitoring, and analysis tools deep within the corporate infrastructure?  Find a kink in this light armour, and you can sail right past the corporate security systems in place.

What type of attacker is interested in exploiting IoT devices?  We are finding that the IoT Threat Landscape is quite varied.  Everyone from cybercriminals to government entities, hacktivists, and even insiders have shown up to the game. It's apparently hard to resist the low hanging fruit of an easily exploitable system, that could lead directly into the corporate infrastructure.  

From stealing sensitive data by hacking IoT devices, to facilitating denial of service against a third-party entity, there are plenty of reasons and opportunities to exploit a connected Internet of Things device.


 

So, as developers, what are we to do? 

How can we ensure that our products are secure from the beginning?  What aids do we have to guide us in creating a more secure, more private consumer product?


I'm glad you asked!  There are many initiatives currently to define the obstacles and opportunities to creating a secure Internet of Things ecosystem, but there ARE some guideline that you can follow.


First, from Cyber Security company I am the Cavalry, here is a snippet of sage advice:

Security:

  1. Secure by Default
    1. No default passwords shared between devices, or weak out of the box passwords.
    2. All passwords should be randomly created using a high quality random password generator.
    3. Advanced features used by small percentage of users should be turned off by default(VPN,Remote Administration, etc...)
  2. Secure by Design
    1. Firmware should be locked down so serial access is not available.
    2. Secure Ethernet (SE) or Trusted Protection Modules (TPM) devices should be used to protect access to the firmware and hardware.
    3. All GPIO, UART, and JTAG interfaces on the hardware should be disabled for production versions.
    4. NAND or other memory/storage mediums should be protected with epoxy, ball sockets (so the memory cannot be removedand dumped), or other methods to prevent physical attack. 
  3. Self Contained Security
    1. The devices should not rely on the network to provide security. Rather, the device's security model should assume the network is compromised, and still maintain protection methods. This can be done with prompts to the user to accept handshakes between devices trying to access other devices on their networks.
    2. Communication between devices should be encrypted to prevent MiTM attacks and sniffing/snooping.
Privacy:
  1. Consumer PII not shared with manufacturers or partners.
  2. Usage data on individual consumer is never shared with partners or advertisers.
  3. Anonymous data for buckets of users on usage patterns is acceptable as long as it's proven to no be traceable back to an individual consumer.
  4. Data collection policy, type of data collected and usage of data is clearly documented on site.



As well, I am the Cavalry has published the Five Star Automotive Cyber Safety Program, with the purpose of bringing the industry together to standardize on a security framework for connected devices.



According to their website:  
The OWASP Internet of Things Project provides information on:

Of interest in this discussion is the topic of "IoT Attack Surface Areas". Each one of these boxes identifies specific threat vectors to IoT product development, as well as guidance and recommendations on remediating these concerns early in the development cycle.


Ecosystem Access Control Device
Memory
Device Physical
Interfaces
Device Web
Interface
Device
Firmware
Device Network
Services
Administrative
Interface
Local
Data Store
Cloud Web
Interface
Ecosystem
Communications
Vendor Backend
APIs
Third Party
Backend API's
Update
Mechanism
Mobile
Application
Network
Traffic


 IoT Security != Device Security


Attack Surface Vulnerability
Ecosystem Access Control
  • Implicit trust between components
  • Enrollment security
  • Decommissioning system
  • Lost access procedures
Device Memory
  • Cleartext usernames
  • Cleartext passwords
  • Third-party credentials
  • Encryption keys
Device Physical Interfaces
  • Firmware extraction
  • User CLI
  • Admin CLI
  • Privilege escalation
  • Reset to insecure state
  • Removal of storage media
Device Web Interface
  • SQL injection
  • Cross-site scripting
  • Cross-site Request Forgery
  • Username enumeration
  • Weak passwords
  • Account lockout
  • Known default credentials
Device Firmware
  • Hardcoded credentials
  • Sensitive information disclosure
  • Sensitive URL disclosure
  • Encryption keys
  • Firmware version display and/or last update date
Device Network Services
  • Information disclosure
  • User CLI
  • Administrative CLI
  • Injection
  • Denial of Service
  • Unencrypted Services
  • Poorly implemented encryption
  • Test/Development Services
  • Buffer Overflow
  • UPnP
  • Vulnerable UDP Services
  • DoS
Administrative Interface
  • SQL injection
  • Cross-site scripting
  • Cross-site Request Forgery
  • Username enumeration
  • Weak passwords
  • Account lockout
  • Known default credentials
  • Security/encryption options
  • Logging options
  • Two-factor authentication
  • Inability to wipe device
Local Data Storage
  • Unencrypted data
  • Data encrypted with discovered keys
  • Lack of data integrity checks
Cloud Web Interface
  • SQL injection
  • Cross-site scripting
  • Cross-site Request Forgery
  • Username enumeration
  • Weak passwords
  • Account lockout
  • Known default credentials
  • Transport encryption
  • Insecure password recovery mechanism
  • Two-factor authentication
Third-party Backend APIs
  • Unencrypted PII sent
  • Encrypted PII sent
  • Device information leaked
  • Location leaked
Update Mechanism
  • Update sent without encryption
  • Updates not signed
  • Update location writable
  • Update verification
  • Malicious update
  • Missing update mechanism
  • No manual update mechanism
Mobile Application
  • Implicitly trusted by device or cloud
  • Username enumeration
  • Account lockout
  • Known default credentials
  • Weak passwords
  • Insecure data storage
  • Transport encryption
  • Insecure password recovery mechanism
  • Two-factor authentication
Vendor Backend APIs
  • Inherent trust of cloud or mobile application
  • Weak authentication
  • Weak access controls
  • Injection attacks
Ecosystem Communication
  • Health checks
  • Heartbeats
  • Ecosystem commands
  • Deprovisioning
  • Pushing updates
Network Traffic
  • LAN
  • LAN to Internet
  • Short range
  • Non-standard



As stated earlier, this is starting guidance on what to look for when building out your Internet of Things Security Framework.  For further ideas and guidance, please read the references below. 

Good luck, and happy coding.




Resources:

OWASP: Top 10 IoT Security Issues
OWASP Top Ten IoT Security - Infographic
OWASP: IoT Security Guidance
RSA Conf: Mapping the IoT Attach Surface Areas
ARSTechnica: “Internet of Things” security is hilariously broken and getting worse
ARSTechnica: Police body cams found pre-installed with notorious Conficker worm
ARM.COM: From Sensor to Server, ARM drives the Internet of Things 
Texas Instruments: Internet of Things - Opportunities and Challenges 
DEFCON 23: IoT Attack Surface Mapping
HPE: Securing the IoT
Capgemini: Securing the Internet of Things
Globe and Mail: Internet of Things a playground for hackers
Globe and Mail: The Future is Smart - Why privacy must be baked into the Internet of Things
https://www.iamthecavalry.org/
IamtheCavalry: Five Star Automotive Cyber Safety Program
https://www.theguardian.com/technology/2015/nov/26/hackers-can-hijack-wi-fi-hello-barbie-to-spy-on-your-children
http://www.computerworld.com/article/2476599/cybercrime-hacking/black-hat-nest-thermostat-turned-into-a-smart-spy-in-15-seconds.html
https://www.exploitee.rs/index.php/Exploiting_Nest_Thermostats
http://www.theregister.co.uk/2016/01/12/ring_doorbell_reveals_wifi_credentials/
Embedded: Security framework for IoT devices
NIST Releases Draft Framework on the Internet of Things
Online Trust Alliance: IoT Trust Framework
WolfSSL: Embedded SSL Library for Applications, Devices, IoT, and the Cloud
http://www.bankingexchange.com/news-feed/item/5770-5-hacks-into-your-internet-of-things-devices
https://www.helpnetsecurity.com/2016/05/09/internet-of-fail/
Cisco: IoT Threat Environment
https://blog.knowbe4.com/worlds-most-famous-hacker-kevin-mitnick-iot-is-exploitable
http://krebsonsecurity.com/2016/02/this-is-why-people-fear-the-internet-of-things/