Hardening Android (4 of ??)

Alternate title: To do or not to do


Welcome back! Glad you're hanging on through my streams of consciousness about my scientific experiment. If you're new to the show, please remember to start from the beginning. There will eventually be a full list of the settings down the road but sharing the experience and technique of analysis is the real message


In the episode before last we took a look at the Settings app and explored it's surface area to discover any settings that might have a security impact. In this installment I want to take you through the next stage of analysis and action around these settings introducing a staged approach to identifying and assessing impact of settings sothis impact can be compared against the needs of the business goal to help decide whether to activate or not.


Before we begin, lets fresh on the original goal though. For our purposes today the goal is the ultimate hardened Nexus 7 so we have a minimal platform to build on. This means it will have the least possible surface area to attack, the least output to facilitate attacks through Private or leaked information, access controls that limit anyone other than the owner from getting in without a pipe wrench and a solid response capability in case of a breach of our defenses.


The hardening algorithm I propose to use is as follows.  As you'll note, the effectiveness of this approach is clearly a matter of my available time and the information and tools available.  Since I have less time than the attackers this is as clear an explanation of why we're losing the defensive battle.   Many of us are seemingly always stuck in step 1 and are lucky when the auditors or regulators are forcing us to proceed to step 2.

1. Decide what is clearly low impact to achieving the goal (aka low hanging fruit) and Reduce or Restrict it. We've been doing some of this so far but now we're going to apply this to settings that could impact any application of the system in a positive or negative way.
   
2. Analyze the remaining inputs and output to identify undiscovered output and attackable surface area.
   
3. Loop to step 1 until I've hit the limits of my knowledge.
   
4. Decide if this is adequate to my goal and research if not.
   
5. If new information is gained, loop back to step 1.
   
6. If no new information is gained, identify sources to monitor to be able to respond to any future new information and repeat step 5 until the platform dies or I decide to upgrade, then destroy the device.
   

Step 1 – Deciding what to Reduce or Restrict.

For this first round, I looked over the list from the previous session with an eye to the goal and a modern understanding of technical terms. In that light, I see some items that, just from their explanation, have clearly low impact on usability with a high impact on attacker discouragement (from the CISSP manual: You can never stop a determined attacker.)

Relative to our goal, the following are the settings that are easy wins in this next round of decisioning so I won't go into a lot of details on these.

1. Wi-Fi – Turn Off till I need it
    b) 3 dots
        - Advanced
           - Keep Wi-Fi on during sleep – Never on
           - Scanning always available – Leave off
           - Wi-Fi optimization – Leave on
2. Bluetooth – Off
4. More
    b) NFC (Near Field Communication) – Turn off.
5. Sounds – Disable all noisy activities
6. Display
    b) Sleep – Set to 15 seconds
12. Location – Turn this off but before you do, set the following so they are in place when you do enable Location.
      b) Google Location Reporting – Turn on Location Reporting then turn off Location History then go back and turn off Location Reporting
13. Security (now we're talking!)
     a) Screen lock – Use password with at least an 8 character complex password
     b) Automatically lock – Immediately
     c) Power button instantly locks – On
     d) Enable widgets – Leave off till we know what this does
     e) Owner Info – Put a message there that says “Not yours!! Do not touch!!”
     f) Encrypt tablet – Yes
     g) Make Passwords Visible – No
     i) Unknown sources – Leave disabled
     j) Verify Apps – Leave enabled
14. Language and Input
      b) Keyboard & Input Methods
           - Google Keyboard
           - Settings button – Sound on keypress – Another place to control the noise output of the device.
           - Improve Google Keyboard – Sends usage statistics to Google – Default is on.
      c) Voice Search > Bluetooth headset – Leave off
16. Accounts > Google
      a) My email – Can manage synchronization of App Data, Calendar, Contacts, Drive, Gmail, Google Photos, Google Play Books, Google Play Movies & TV, Google Play Music, Google Play Newsstand, Keep, People details, Sound Search for Google Play (what is this?) - Disable all sync
      b) Search > This is Google Now and it is off as I'd requested.
17. Date & Time > Automatic data & time – Use network provided time –Leave on
18. Accessibility
      a) Talkback – Leave off
      c) Speak passwords – Leave off
19. Printing – Disable all
20. About – Touch Build Number 7 times and get to Developer mode – leave off

Now we've gotten somewhere. We once had 124 features under Settings that could be used to protect information and now we're down to 85. Not bad for a few hours work!!

Next: Step 2: Scanning, proxying and log reviews to further understand the inputs and outputs before we start disabling apps and other features.