The majority of security problems in app development are really software quality problems. There’s something wrong with the way the code was written that leaves a door open for someone to exploit. Fortunately, many of these problems can be easily fixed. Some of these can be fixed in the design phase of product development and others in the code phase. We’ll explore a few examples of each type in this post.

The Objective of this Post

Now, before we jump in, I need to confess that this is a broad and deep subject. My goal here is to present a high-level understanding of code security through discussion and a few examples that will help you understand the kinds of vulnerabilities that can lead to problems. I will also provide references to further reading for those that really want the “Full Monty” on developing secure apps.

Code Security at Design Time

1. Design with security in mind. This is perhaps the most important thing you can do. Think about the following questions before you design your code and have answers for all of them:
   • What Assets does this software need to protect? Credit Card numbers, user data, contact lists, account info, access to paid services, and privileged access to device. To protect sensitive assets, you need to plan how you’re going to deal with the data at design time. If you’re sending sensitive data over a computer network, you should use SSL/TLS protocol to prevent attackers from eavesdropping. Look into OpenSSL for open source libraries and code examples on how to use this protocol. Also, for server-side storage, consider using a 3rd party database such as MySQL. These systems have their own built-in security policies that you can leverage. Also, for secure authentication, leverage trusted services like OAuth and OpenID (See Additional Resources for more info below)
   • How might an attacker exploit my code? This is often called “Thread Modeling”. Attackers might be eavesdropping on the network ports you use, or providing unexpected inputs that overflow memory buffers and inject attacker-supplied code to be executed. You have to ensure, for example, that you never execute code on behalf of an untrusted user
2. Follow a Secure Coding Standard – Select a secure coding standard and make sure your code conforms. A secure coding standard will identify specific issues with a particular programming language that a compiler or analysis tool might fail to diagnose. Secure coding standards also define requirements for producing code level security in your system. Several popular secure coding standards are available from CERT® on their website at www.securecoding.cert.org.
3. Perform Design Reviews. This is a simple thing teams can do, and it can really pay off in the long run. A few years ago, I managed a couple of engineering teams at Sun and when a new code module was planned. The engineering lead would present the design to a team of Senior Architects with different backgrounds (JVM, networking, platform architecture, etc.). This always uncovered potential problems –and did so early on before they became big problems that were expensive to fix.
4. Understand Emerging Threats. Pay attention to the type of exploits that are popular, and make sure you’re not helping the bad guys. Designate one person on your team to stay up to date on the current security trends and put her/him in the code review. A great place to start is by visiting the CERT website frequently and becoming familiar with all the resources they offer. In addition, all major platform and OS providers publish security updates from time to time as issues are uncovered.
5. Use Static Analysis Tools. Static code analysis can really help locate many kinds of software validation and reliability problems, including many memory problems. Some examples of companies that provide these products include: Klocwork and Coverity, Parasoft, and Vericode. A more complete list can be found here: http://www.cert.org/secure-coding/tools.html

If you’re doing all these things, you’re actually doing pretty well. You’ve got a solid design, you’re following a secure coding standard, you’ve got someone keeping an eye out for potential security exploits, and you’re conducting design reviews and running static analysis tools on a regular basis. You’ve got the design side covered pretty well. Now let’s look at some specific code issues that can cause problems.

Code Security at Development Time

Most of the following examples demonstrate some of common problems found in native C and C++ development. Web developers and Java developers can still benefit as the concepts behind the problems are valid in many languages. In the Additional Resources section below, I provide links to specific Web and Java resources for code security.

1. Application Frameworks

   Use application frameworks whenever possible. Frameworks hide a lot of the nasty memory management and secure network connection issues from the developer and reduce the possibility of making simple, but costly, mistakes. Fortunately, the BlackBerry platform supports a lot of great developer frameworks, both from BlackBerry (such as the Invocation and Share Framework, and the UI Framework Cascades) and through BlackBerry’s Platform Partners.

2. Memory Management

   Aside from the obvious allocation of memory insufficient for the data you’re writing into it, there’s a common issue people new to C and C++ sometimes experience regarding memory management. The problem occurs when you confuse which action you use to release the memory you’ve allocated.

   Using Cascades will reduce the likelihood of memory management problems because it hides all the messy details for you within the framework. However, if you must allocate memory yourself for your app, keep the following tip in mind.

   There are two main C functions for allocating memory: malloc() and calloc(). Use malloc() when you don’t care about initializing the data in memory. Use calloc() if you want to initialize the memory to 0. The important thing to remember is when using either malloc() or calloc(), you must use the function free() to release the memory and give it back to the system.

   In contrast, when using the C++ method new() to create a new object, you must use the corresponding delete() method. Nothing good can happen when you call free() on memory you’ve created using new().

3. Function Safety

   The QNX platform provides a number of preferred C functions that are safer to use than the more commonly known standard functions. A subset of these is shown in the table below. You can find the complete list in the BlackBerry Native SDK online docs (referenced in Additional Resources section below).

   As with memory management, using an application framework helps with function safety as well. For instance, the Cascades classes such as QString and QByteArray protect you from many of these problems as well.

   As you’ll see in these examples, most of the serious problems occur when buffers you’re reading into or writing out to are not large enough to take the data. These functions below help you from over-writing some of the time. You should always perform bounds checking if you want to be on the safe side.

   Unsafe Function(s)	Preferred Function(s)	Comments
   strcpy() and strncpy() strcat() and strncat()	strlcpy() and strlcat()	The function strlcpy() copies strings and the function strlcat() concatenates strings. They’re designed to be safer, more consistent, and less error-prone replacements for strncpy() and strncat(). Unlike those functions, strlcpy() and strlcat() take the full size of the buffer (not just the length) and guarantee to NUL-terminate the result (as long as the size is larger than 0 or, in the case of strlcat(), as long as there’s at least one byte free in the destination string). There also exist “wide” versions of these functions that are equally dangerous: wcscpy(), but there is no “l” safe version to use, only wcsncpy() which does not necessarily NUL-terminate the output. Care must be taken to ensure the output buffer is NUL-terminated.
   sprintf() and vsprintf()	snprintf() and vsnprintf()	The snprintf() function is similar to fprintf(), except that snprintf() places the generated output (up to the specified maximum number of characters) into the character array pointed to by buf, instead of writing it to a file. The snprintf() function is similar to sprintf(), but with boundary checking. A null character is placed at the end of the generated character string.
   gets()	fgets(buf, n, fp)	The fgets() function reads a string of characters from the stream specified by fp, and stores them in the array specified by buf, limited to size n.
   getwd()	getcwd(buffer, size)	The getcwd() function returns the name of the current working directory. buffer is a pointer to a buffer of at least size bytes where the NUL-terminated name of the current working directory will be placed. The maximum size that might be required for buffer is PATH_MAX + 1 bytes

4. Structures

   Structures in C and C++ are aggregated types that define and contain other data elements within them. The elements of a structure cannot be re-ordered by the compiler. Modern compilers do use a variety of methods to minimize the security risk of stack-buffer overflows such as stack canaries, address-space layout randomization, re-ordering the local variables within a function, among other things. However, since the compiler can’t re-order the elements within your structures, the possibility of a buffer overflow on one of your elements affecting function parameters or local variables remains. Consider the following example:

   struct _JOB {
               char name[64];
                           char title[64];
               DATE startdate;
               DATE enddate;
               WAGE salary;      
           } JOB, *PJOB;

   The buffers name and title can both overrun. Since they’re placed on the stack first, the elements defined after them in the structure and on the stack itself can be affected. For this reason, care should be given when defining the elements in a structure. The next example shows a structure that’s defensively designed:

   struct _JOB {
               DATE startdate;
               DATE enddate;
               WAGE salary;  
               char name[64];    // Buffers placed at end 
                           char title[64];   // of struct definition
   
           } JOB, *PJOB;

   Recommendations for using structures

   When dealing with structures that contain fixed-width buffers or arrays designed to receive data that’s controlled or influenced by a user:

   • Buffers and arrays in structures should be grouped at the end of the structure
   • Local variables declared as structures should be declared after local buffers but before any other local variables
   • Global variables declared as structures should be declared before any global buffers and arrays and after any other global variables
   • Pointers to structures do not need any special consideration
   • Where practical, try to minimize the number of local variables cast as structures with buffers and arrays as elements

5. Macros

   Macros are one of my favorite mechanisms in C and C++. I love using them; however, you have to be very careful as they can get you into trouble. Macros are defined through the use of the #define preprocessor directive and when processed, literally expand in your source code prior to compilation. If IDE’s could show you what the processed source code looked like (maybe some do?), then I suspect we’d see fewer problems. Consider the following example that demonstrates the issue:

   #define CUBE (x*x*x)
   …
   int x = CUBE (5-2)

   In this example, you might expect that you’re going to get the cube of 3 which is 27. However, when the preprocessor expands the macro, normal operator precedence rules apply. So, here’s how that the value of x will be calculated:

   CUBE(5-2) = (5 – 2*5 – 2*5 – 2)
   CUBE(5-2) = (5 – 10 -10 -2)
   CUBE(5-2) = -17

   Therefore, to protect against this problem, the macro can easily be defined using parentheses as in:

   #define CUBE(x)   (x)*(x)*(x)

   In this example, we’ve seen how operator precedence rules can get you into trouble with macros. There are other problems such as the importance of white space when defining macros, using macros in if statements, and self-referencing macros to name a few. Provided you think about how the macro will expand in your source and you consider how the arguments you pass to macros will be interpreted in that expansion, you should be fine.

6. Integers (signed, unsigned) and Enumerations

   Another common problem that can expose serious threats to your code involves integer overflow or underflow. This can happen when care is not taken with integers. The following code fragment demonstrates how serious this problem can be (recall our discussion about buffer sizes above):

   int buffLen = 0;
   printf(“[buf] %d %u\n”, buffLen, buffLen);
   buffLen = -1;
   printf(“[buf] %d %u\n”, bufflen, bufflen);

   Executing this code gives:

   [buf] 0 0
   [buf] -1 4294967295

   In this example, I forced the value of bufLen to be -1 for demonstration purposes. But, it’s easy to imagine a simple arithmetic error in a length calculation to be off by one.

   Similar problems arise with the use of Enumerations. Not all compilers use the same kind of “int” for Enumerated types. So, you need to be careful when using Enumerations. Make sure you know how your compiler treats them. If your compiler uses signed integers by default (such as Microsoft Visual C++ and ARMCC), it’s not possible to create an unsigned enumeration as the value will be overflow the signed int (for example, you can’t set the enumerated value to be 0xffffffff).

Summary

Though we’ve just scratched the surface of this topic, we’ve discussed a number of things developers can do to protect their code from security problems.

We’ve explored good practices developers can adopt at design time, such as:

• Design with security in mind
• Follow a Secure Coding Standard
• Perform Design Reviews
• Understand Emerging Threats
• Use Static Analysis Tools

We’ve also looked at some common coding mistakes that can lead to security problems and discussed how the code can be fixed to avoid these problems. We’ve seen how leveraging Application Frameworks (like Cascades) can greatly reduce security problems. As an app developer, you have a responsibility to protect your user’s identity and sensitive data as best you can from attackers seeking to exploit it. The content in this blog post should help you get started with some good practices and links to learn more.

For more information on application security, additional examples, and deeper analysis, please refer to the additional resources below.

Additional Resources

• BlackBerry Native SDK Online Docs. Security Considerations for Native Application Development
• QNX Online Docs, Neutrino C Library Reference
• Chad Tetreault, Say It Aint S’OAuth, in BlackBerry Dev

Blogs

• Software Engineering Institute | Carnegie Mellon http://www.sei.cmu.edu/
• Seacord, Robert. The CERT C Secure Coding Standard, Addison Wesley, 2008
• Seacord, Robert. Secure Coding in C and C++, 2nd Edition, Addison Wesley, 2013.
• Mark Dowd, John McDonald, Justin Schuh, The Art of Software Security Assessment

Acknowledgements

I’d like to thank Robert Seacord for taking the time to read an early draft of my blog and provide helpful feedback. Robert is a senior analyst in the CERT Program at the Software Engineering Institute (SEI) in Pittsburgh, PA where he leads the Secure Coding Initiative and is author of a number of books on Secure Programming. I’d also like to thank the BlackBerry Security team for their insightful comments and suggestions.

This is the first post in a two part series about security. In this post, I tackle the issue of responsibility. In Part II, we’ll explore some things that developers need to know to help them write secure apps.

I sat on a panel recently at Sprint’s Open Solutions Conference in San Jose titled “Consumer Application Security for Developers”. Sexy topics like application security rarely pack a session hall at any conference and this was no exception. However, the attendance was much higher than I expected (about 30 people) and the discussion was very lively and interactive. It was immediately clear to me that developers – perhaps as consumers themselves – are thinking more about security than they had in the past. This is a good thing.

Whose Problem is Security?

One of the first questions that came up in the panel was: “Whose problem is security?” Our moderator suggested a number of potential “owners” for this problem and posed the question to his panel. Is it the carrier’s problem? How about the Handset OEM? The OS? Your employer’s IT admin? The app developer? The consumer? As you can see, there are a lot of parties to point fingers at when something goes awry.

I couldn’t help but jump on this one first. The answer is obvious: Security is everyone’s responsibility. Each player in the mobile device value chain is responsible for providing a secure environment over the part they control. At its most fundamental level, security is about protecting valuable assets from those who seek to steal or exploit them. You wouldn’t leave your house in the morning without locking the door, right? Even greater diligence is required in the digital world because the value can be greater, and the thieves are invisible.

Security is everyone’s responsibility

The Carrier: The carrier is responsible for providing a network that is secure from being attacked, snooped, or otherwise compromised. As carriers reduce their investments in their own app catalogs, their responsibility with app security lessens but responsibility for cellular and data network integrity remains.

The Device: The device’s operating system (OS) is at the center of security. The OS’s responsibility is to provide a secure environment for all applications, services, data storage, and network connectivity. The OS is responsible for handling permissions and defending against viruses and malware. Attackers primarily seek to exploit weaknesses in the OS or in its core applications such as web browsers. This is why it’s so important to design security into the OS when it’s being architected and built. Platform providers that offer App Stores have an additional responsibility to ensure that the apps it stocks in its store are safe from malware and abuse like piracy. It should be no surprise to anyone that RIM takes the issues of security very seriously.

The IT Administrator: The number one responsibility of IT at any high-tech company is protecting the company’s Intellectual Property (IP) –it’s like the crown jewels of the company’s value. In a world where IT administrators directly managed the mobile devices that had access to the company’s jewels, their ability to protect them was pretty clear. However, with today’s BYOD trend, their ability to protect the company’s assets and IP has become less clear. Only RIM has addressed this uncertainty and given control back to IT administrators and CIOs with its BlackBerry Mobile Fusion (IT’s MDM Portal) and BlackBerry Balance (the client side partitioning; controlled by a simple gesture). With these products and services, IT administrators can enforce corporate security policies and manage remote devices with confidence.

The App Developer: App developers have a responsibility too. It’s their job to build an application that can’t be exploited by attackers and protects sensitive information that the user provides. Strong operating systems provide many mechanisms for app developers to ensure their app isn’t the “unlocked window” that gains access to someone’s identity or bank account. App developers need to think about security as an end-to-end problem. This includes making secure network connections, encrypting local data on the device, and ensuring servers with sensitive customer data are adequately protected from attack.

The Consumer: Consumers need to be mindful as well. Use device passwords (and not “1234”) and, perhaps most important of all, be suspicious of applications asking for permissions to access files, social networks, and your contact list. RIM offers a great product for consumers called BlackBerry Protect that helps keep the information on your device backed up and secure should your device get lost or stolen. BlackBerry Protect also allows you to wipe all the data off your device remotely as well as display an alert message on the home screen should you lose your BlackBerry device.

Why is BlackBerry 10 so secure?

BlackBerry 10, RIM’s upcoming mobile computing platform, is built on QNX’s Real-Time Operating System. Sebastien Marineau, VP of OS Platforms at RIM, wrote a great article recently titled “How BlackBerry 10 avoids Android’s Security Issues”. In the article, Sebastien notes that the QNX RTOS has approximately 100,000 lines of code whereas a standard Linux implementation is around 14 million lines of code. QNX is 1% the size of Linux. When it comes to security, the fewer places where bugs and security exploits can hide, the better! Because QNX is so tight, and because it’s been designed with security in mind from day 1, it’s extremely hard to break in.

In addition, BlackBerry 10 includes BlackBerry Balance: a new, unique, and innovative capability that allows consumers to enjoy the full range of both a personal mobile device and a secure, encrypted work device without compromising on either one. No other mobile device can do this. With one simple gesture, the user can switch the device from “Personal” mode (wide open with all their apps, music, media, etc.) to “Work” mode (fully secure as if on your work’s VPN). Using BlackBerry Mobile Fusion, IT administrators can manage their company’s devices remotely and securely (including Android and iOS devices!).

In this blog post, we explored the responsibility of security — who owns what piece and why it’s so important. My next post on this topic, titled “Application Security Part II: What Should App Developers Do?” will explore different things developers can do to make sure they’re writing solid, high quality, secure mobile applications.

There are many great things about developing for the BlackBerry platform – including our commitment and support of open source technologies and multiple development languages (Native, HTML5 with BlackBerry® WebWorks™, Adobe® AIR®, Java®). One thing we’ve really invested in over the last year is to respond to developer feedback and requests, in order to enable you to build the way that’s best for you. One of the areas we’ve been focusing on especially is code signing.

What is Code Signing anyway, and why does BlackBerry code sign?

Code signing has been designed to provide security for consumers. They can feel confident that the application they are installing has not been modified after it was signed by the application developer. Code signing is also a means for applications to protect their data.

Code signing has many benefits for both developers and consumers. Developers can distribute an unsigned version of their application along with a debug token to a limited set of beta testers. The debug token helps to ensure that only those beta testers that a developer has issued a token to can run the application. I’ll walk through this process in more detail in a future blog post.

Debug tokens also allow for central key management, allowing for a single code signing key to be used by a team of developers testing an application. Debug tokens can be issued to each developer, allowing them to test builds on their BlackBerry® PlayBook™ tablet. The code signing key can be deployed to a secure build server, protecting it and ensuring that only official builds of the application are signed for public distribution.

BlackBerry® Tablet OS applications each have their own sandboxed private data area that only the application itself can access, which is protected in part by the code signing key. This can prevent a malicious application from impersonating another application. If a malicious application – signed with a different code signing key – were to attempt to masquerade as an upgrade to an existing application the user has installed, it would install it as a new, unique application and it would not have access to the private data area of the original application. This makes it important to back up your code signing key because if you lose it, you’ll be unable to provide upgrades to your application.

Data protection isn’t just limited to BlackBerry Tablet OS applications. BlackBerry® 7 OS (and lower) support similar data access control through the use of a custom code signing key. You can read all about that here.

What We’ve Been Doing over the Last Year

We’ve made a number of improvements to code signing over the last year and we will continue to build on this in 2012. Here is a rundown of what we’ve done so far:

• Made code signing keys easier to obtain by removing the credit card requirement for ordering them
• Reduced the order time for code signing keys from 7-10 days to approximately 1-2 hours so you can start building right away!
• Created Configuration Wizards to walk you through configuring and backing up your keys
• Automated many previously manual steps by integrating Debug Tokens into the SDKs
• Updated the hardware for our code signing servers
• Created the Code Signing Supportsite to walk through the ordering, configuration and signing process

This is by no means the end of the road when it comes to improvements. The golden age of code signing will arrive when you can request keys instantly from the SDKs themselves and have the tools take care of all the dirty work for you. We’re actively re-writing the code signing infrastructure to accommodate this in the future.

The Future Is Secure AND Easy

These are just some of the major benefits that code signing provides. Of course, in any situation, the benefits have to outweigh the effort. We hope to achieve a near zero effort for code signing for both developers and consumers.

Got questions about the code signing process? Let us know in the comments!

In part one of our three-part series on BlackBerry® security, we discussed the nuances of enterprise IT policy. Today, we’ll discuss application control.

In contrast to IT policy, which IT administrators use to manage and control employee use of BlackBerry smartphones, application control refers to a security setting that can be managed by the end-user and/or the IT administrator (if the user is connected to a BlackBerry Enterprise Server) that defines application behavior on BlackBerry® smartphones.Specifically, application control allows IT administrators to define whether or not applications can make network connections, play media, access the BlackBerry® Calendar… etc.

These settings are configurable by either the end user or the BlackBerry Enterprise Server admin. It’s important to note this subtle difference: because application control can be configured by the user, the BlackBerry smartphone does not need to be connected to a BlackBerry Enterprise Server to use them (whereas for IT policy to be applied the BlackBerry smartphone has to be connected to a BlackBerry Enterprise Server).

BlackBerry smartphone users with experience installing applications are likely familiar with application control. In BlackBerry® Device Software 4.6 (first introduced with the BlackBerry® Bold™ smartphone) and above, users encounter application control as soon as the installed application is first executed:

“Would you like to grant [Application Name] Trusted Application status?”

If the user selects “Yes”, then your application will be given all the permissions commonly needed for normal execution, i.e. all permissions will be set to “Allow” with the exception of:

• Prompt – Recording, Security Timer Reset
• Deny – Input Simulation, Browser Filtering, Display Information While Locked

Alternatively, if the user selects “No”, it’s not the end of the world; it just means that your application will be given the default set of permissions. For BlackBerry smartphones that are connected to a BlackBerry Enterprise Server, all permissions are set to “Allow” with the exception of:

• Prompt – Recording, Phone, Location Data, Server Network, Internet
• Deny – Browser Filtering, Input Simulation, Security Timer Reset, Display Information While Locked

For smartphones that are not connected to a BlackBerry Enterprise Server, all permissions are set to “Allow” with the exception of:

• Prompt – Recording, Phone, Location Data
• Deny – Browser Filtering, Input Simulation, Security Timer Reset, Display Information While Locked

Regardless of what the user selects, on first run of your application, it’s a good idea to check what permissions are assigned to your application, using ApplicationPermissionsManager.getApplicationPermissions(). All application permissions have a setting of “Allow” and “Deny”, and some have a tertiary setting:  “Prompt”. If a permission is set to “Prompt”, the user will receive a dialog like the one below when you use an API that triggers it:

“The application [Application Name] has requested a http connection to [domain X]“

At this point, the user is given the choice to “Allow” or “Deny” the request. If they select “Allow” (and check the box to not be asked again), the value of the permission will be changed from “Prompt” to “Allow” and your API call will succeed.  However, if the user selects “Deny”, then your application will receive either a ControlledAccessException or a SecurityException, depending on the method definition.

It is probably best to avoid these prompts in the first place. Since there’s no magic formula that will allow you to eliminate all these prompts, your best bet is to group them into a single request, using ApplicationPermissionsManager.invokePermissionRequest (ApplicationPermissions requestedPermissions) for the permission values your application will require. Calling this method will first present the user with a dialog indicating to the user that your application is attempting to change permissions, and then display a screen with all requested permissions, which requires the user to save the settings presented to them. Since developers don’t have the ability to control the user interface for either of these screens, it’s recommended that you inform the user what your application is about to do before blindly launching into the permission request.

Lastly, if despite all your best efforts, the user still hasn’t granted you permission access beyond “Prompt”, you do have the ability to provide more information to the user explaining your reasoning for leveraging a certain function. To explain, let’s return to the http message we got:

“Would you like to grant [Application Name] Trusted Application status?”

Using the ReasonProvider API, you can attach your own message to this dialog prompt, contained within a link for “Details…”. If the user clicks this link, your message will be displayed to the user, allowing you to explain why your application needs this permission:

“My application needs to open a network connection so that it can download pictures from your favorite website.”

This approach eases the minds of your users by providing them all the information they need to make confident decisions about your application.

For more information on the various application control settings that can be applied to your application, see the Javadoc for the ApplicationPermissions class, which defines constants for each permission.

In part three of this series, we’ll address the topic of code signing. Stay tuned!

So you’ve had your stroke of genius, you’ve developed the BlackBerry® smartphone application that’s going to sell a million copies on BlackBerry App World™, and you’re ready for your final end-to-end testing on a live device.  You put the application up on your web server, enter the URL into the BlackBerry® Browser, choose the option to download, and then half way through, the download comes to a halt with this message:

“This application does not contain a signature. It might not be from a trusted source. Do you want to proceed?”

Your mind starts racing.  “How are my users going to react?  How do I make this message go away?”

This is the first of a three-part series of blog posts that will outline how consumer applications are handled from a security perspective in the enterprise with BlackBerry Enterprise® Server.  First and foremost, it is important to understand that there are two categories of security to consider: IT policy and application control. In part one of this series, we’ll cover IT policy; in part two, we’ll cover application control; in part three, we’ll talk about code signing and how that affects application development regarding these two categories.

IT policy is a security setting in BlackBerry Enterprise Server that IT administrators in medium-to-large sized organizations use to manage and control employee use of BlackBerry smartphones.  For example, an IT administrator could set an IT policy that allows or prevents use of the camera, phone service, the browser, etc.  IT policy only applies to users who are connected to a BlackBerry® Enterprise Server.

When are you most likely to encounter IT policy? Typically only in organizations that require some level of security.  As an application developer, if you don’t have the time to learn about all of the various IT policy settings that can affect the use of your applicaton within these organizations, then at least take note of the big one: Disallow Third Party Application Download.  How will you know if you’ve run into this setting?  When downloading an application via over-the-air download, users will get the following error:

“Download Failed: 910 Application authorization failure.”

In order to get your application on this user’s BlackBerry smartphone, you’ll need to convince the BES administrator to either relax this setting or white list your application.  The good news is that smartphone users are not likely to encounter this setting very often at all; most administrators will use the default IT policy settings that are set in BlackBerry Enterprise Server, and these settings are application friendly.

For more information on IT policy settings for BlackBerry smartphones connected to a BlackBerry Enterprise Server, please see the BlackBerry Enterprise Server Policy Reference Guide.  Note:  Should you wish to query any IT policy values from within your application, see the javadoc for the ITPolicy class.

Stay tuned for part two of this series!