Mobile devices - The backdoor to your enterprise

In the past years, mobile devices and smartphones in particular have presented a new threat to the leakage of information from the organization. The CEO's iPhone was lost and his emails are now exposed to the world, or maybe worse, the Sysadmin's blackberry with some passwords or other important data was stolen. Well, there are many ways that can help you assist minimize the risk by remotely revoking or erasing the device, and I am not going to discuss those.
The huge install base of the iPhone and Android devices is very appealing to hostile entities who wish to penetrate your organization's shield and retrieve information or maybe just damage it. Be it Cybercrime criminal or Cyberwar soldiers, these mobile devices have become their gateway to your fortress, and they are not that protected.
Apple offers the iTunes store where you can download thousands of applications for your iPhone. Are these apps secured, well, some are, and most of them are really harmful, well let's just say for the sake of the discussion they are.
Google offers a huge Market place for Android applications, developed under the umbrella of the open source community, which allows a variety of apps which anyone can develop. Are these apps verified as secured, well they might be, but then again their not really checked, not each and every one.
Let's take a simple scenario where an app is checked and it seems secured. But if someone creates two apps that each on its own, is harmful, but when put together on the same device can become hole for the dropper. The dropper, is a payload carrier for hackers to put any kind of code they wish to hijack your device to their needs.
The problem becomes very clear, when you jailbreak an iPhone, in that case, the jailbreak application or its process can leave a hole for that same purpose. It might be later, when you download a cracked app that you can find on Cydia, or maybe the one you downloaded from a torrent site somewhere, can be this mobile Trojan horse.
The next stage will be for this Trojan to collect your stored credentials to gain access to your corporate network, or maybe to place another dropper that will place a Trojan the minute you plug your iPhone to your computer, and their in.

For now there is no real way to identify a jailbreak iPhone remotely, since Apple cannot keep up with the ones who develop it. Some even say that they are silently dropping the SDK that was used for that, which other companies used to develop product that would block it.
There is not much to do around that except be smart. Here are some tips I could think of that might assist in this situation, at least until someone comes up with a solid solution.

1. Communicate and educate users about these threats, so they will be aware of the consequences.
2. Set a policy that allows only iPhones that have not gone through the jailbreak process to be connected to your servers.
3. Consider using an anti-virus application on your mobile devices. 
4. Recommend that the iPhone will be used for business purposes only – well, as much as possible.
5. Enforce password access to unlock  these devices.
6. Purchase and install certified apps only.
7. Make sure you can remotely disable and wipe the device in case it was lost or stolen.

I guess there are many more that others could think of. If any comes to your mind, you can leave a comment or maybe send me a note and I will include them.




Be safe.
Partykof



 

Naming conventions in IT environment

This post is intended to provide a common set of guidelines useful when handling large number of records in your IT environment, records such as usernames, computer names, devices and other records, by applying some naming convention to these records and explaining the standard settings that will help others understand these conventions and schema. One common way of differentiation between elements is using suffix names, that is if your environment spreads across multiple countries or domain names. The scope of post is related to prefix differentiation which is a problem in local environments or databases.

Not much attention is given to naming convention in the IT environment, especially when starting out small. I remember my first network carried out names of characters from Joseph Heller's novel, Catch-22. At first it was just for fun and it was very easy to remember Yossarian, Milo, Orr, and majorx4 (Major major major major). As my network got bigger, I ran out of funny name to choose, and things started to get complicated. I started using characters from the Greek, Roman and Viking mythology, till it became a nightmare. I had to come up with a method that will help me identify nodes without remembering look-up tables in my head, so I stated looking for some kind of format that later on became very useful when I used an asset management tool.

In large network it is very common to use of some kind of database that holds records. Be it an LDAP (such as Active Directory), Yellow Pages YP/NIS, a DNS, a DHCP or a CMDB. This is why it is necessary to keep in your environment unique values for records such as computer names, usernames, asset tags and email addresses, so you can differentiate between them.

Reasons for using naming conventions:

1. The need for standards and uniformity
2. The use of logic to quickly identify objects
3. Granular differentiation of elements, versions, locating and security reasons
4. Uniqueness or records, in databases such as IDM, ITAM and others like those mention above

There are many ways you can differentiate between elements, here are some examples.

Physical differentiation – by the location of the object such as:

• Subsidiary city
• Building number
• Floor/Level number
• Room number
• Factory line number
  

Logical differentiation – by the relation of the object such as:

• Ownership - Owner user, Department, Organization Unit or Cost center
• Type- Printer, Server, Computer, Switch, Filer, Desktop, Laptop, Phone or Tablet
• Function – Email, DB, Web or File Servers
• Permissions – Anonymous, Standard, Administrator user and so

 Figure 1: Physical and Logical differentiation in Top to Bottom view

Here are some examples that might clearly the idea. First examples relate to users and employees names. I'll use my domain as an example but it can be any domain. The primary objective is to have uniformity in the convention when selecting computer names, usernames, email addresses or any other identifies, as they may affect the use in an Identity management tool.
Let's take John Doe For example, let's say that John belongs to our Chicago office, his office is in building A, he works in the marketing group, and he has a laptop, a portable projector and a mobile phone.

His employee name – Should be recorded as John Doe, not john doe, John doe, Dow john, J0hN doW! or any other combination. If you have another John Doe in your company, you may use his middle initial or any other distinguishes.

His user name - Can be set by using his Surname and a first letter from this First name such as doej or the other way around johnd or b adding another identifier, Doej01.
His email address – should be set from his employee name, such as John.Doe@partykof.com.

Notes:

1. You should avoid using his username as the external email address as it can giveaway his username, which makes it easier for hackers to brute force their way in.
2. I prefer using the dot (.) to differentiate between first name and Surname and reserve the underscore (_) to differentiate between different names, and the dash (-) for concatenated surnames. For example John_Michael.Doe-Benz@partykof.com
3. In cases where the user has a very long name, such as John's it might be wise to shorten the email address, JM.Doe-Benz@partykof.com

Now for John's devices, The little background we got might help us decide on suitable names for his devices.

His devices might be named as:

His Laptop - chamkt-doej-lt
His Projector- chamkt-doej-pj
His Mobile Phone - chamkt-doej-mo

I used the following schema:

CH for the Chicago branch
A for building A
MKT for marketing
DOEJ for his username
MO for mobile, PJ for projector, LT his laptop.

Some other devices around John might be:

chamkt-prt1  - his departmental printer
chamkt-plt1 - his departmental plotter
chamkt-fs1 - his departmental file server
cha-sw-core1 - his building network core switches
ch-srv-ex1 - his branch exchange server

Other areas in IT where you can use naming conventions in a similar concept are:

• Storage Systems – Filers, Aggregates, Volumes, Luns, Folders
  
• Storage Networks – Fabrics, Zones, Switches, WWNs, WWPNs
  
• Networks – WAN and LAN elements, VLAN, VPN, DMZ, firewalls, Routers, Access Points.
  
• Applications - Databases, Tables,

Now remember, these are only examples. You should choose your own schema for your naming conventions as it best suites your organization. There are, however, some basic rules you should comply with.

Basic Rules

• Avoid using non-alphanumeric characters use only letters (A-Z) and numbers (0-9) in your computer names. Underscores and other characters may cause problems with DNS services.
• Use up to 15 characters for computer names, as some services such as NetBIOS and WINS are not compatible with more.
• Avoid using duplicate names, even if they are in different levels which are permitted. In some cases they can cause mix-ups, such as in the case of AD forests and OUs
• Avoid schemes that will lock you in cases of mergers
• Although AD supports it, a user name should not contain a space: for example, user name; as many systems do not support it.

Other Guidelines

• Keep names short and meaningful as possible
• When using usernames within the computer name, remember to change the computer name when you assign it to a different user.
• Build your naming conventions in a top to bottom hierarchy, your prefix should start with the top element.
  

Some References:

1. Naming conventions in Active Directory for computers, domains, sites, and OUs
   
2. Special characters in user ID and passwords
   

Summary:

Naming records in a consistent and logical way will help distinguish between records in a glance. Naming records according to agreed conventions will make naming records much easier for all IT parties, it will streamline adoption of management application or new systems and allow a simple expansion of your organization.

-Partykof