5 Reasons you should download Webeecam – Android USB Camera App today!

#1 Connect your favourite Webcam to your Android Phone
Webeecam is a leading Android USB Camera application for Android Phones / tablets and on installation supports any off-the-shelf USB Video Class based Web camera connected to the Android phone.

#2 Webeecam is a product developed by camera experts
Webeecam is developed and sold by e-con Systems, an end-to-end camera solutions company. e-con Systems offers OEM camera products, software, drivers, customization services and image processing expertise for customers with camera requirements.

Over 50 man years of camera expertise is behind the brain of the Webeecam application.
#3 The only Android Mobile application that supports complete camera and sensor controls of the USB Camera and intends to support multiple frame formats like Bayer, YUV, etc.

#4 Completely customizable SDK that can be customized as per the customer needs. e-con Systems has business models where it can license the SDK binaries and source code for end application integrations.

#5 Assured Support – e-con Systems has a dedicated camera support team that would also support Webeecam. There is continuous investment on Webeecam (with weekly updates) increasing the number of cameras it supports and also the phones it supports.

Android RIL Architecture

 




Introduction
The document explains about the building blocks of Android telephony and how it works
Android telephony architecture

Android RIL Architecture

Application:  All the telephony related applications like Dialer, Call tracker, SMS, MMS, GPRS, Antenna signal indicator and etc, will come into this section. All these applications will be started during the android boot up. These applications will be tied up with the Android telephony framework services. The telephony framework provides APIs to access the Phone.
Framework services: Telephony framework will be initialized and started during the system start up. All the queries from the application through API will directed to the Radio interface Layer of Android by these services. The service will keep tracking of all the unsolicited commands from the modem. Unsolicited commands are the commands initiated from the modem.
Radio Interface Layer: It is the bridge between Android phone framework services and the hardware. In other words, it is the protocol stack for Telephone.  The RIL consist of two primary components.

1. RIL Daemon
2. Vendor RIL

RIL Daemon
RILD will be initialized during the Android system start up. It will read the system property to find which library has to be used for Vendor RIL, provide the appropriate input for vendor RIL and finally calls RIL_Init function of Vendor RIL to map all the Vendor RIL functions to the upper layer. Each vendor RIL has RIL_Init function.
Vendor RIL
It is a library specific to each modem. In other words, we can call it as a driver to function the modem. The RIL daemon will call the RIL_Init function with the device location (eg: /dev/ttyS0). It will initiate the modem and returns theRIL_RadioFunctions structure contains the handles of radio functions

type structure {          intRIL_version;          RIL_RequestFunconRequest;          RIL_RadioStateRequestonStateRequest;          RIL_Supports supports;          RIL_CancelonCancel;          RIL_GetVersiongetVersion;   } RIL_RadioFunctions;

RIL_version : Version of Android RIL
onRequest : Call to Vendor RIL to make a RIL_REQUEST. It must be completed with a call to RIL_onRequestComplete().It will always be called from the same thread, so returning here implies that the radio is ready to process another command (whether or not the previous command has completed)
supports              : Return current radio state.RADIO_STATE_UNAVAILABLE should be the initial state
getVersion          : Version of Vendor RIL
There are two forms of communications in Android RIL
Solicited Commands :These are commands initiated from the upper layer. Like, Dialing/Send SMS are the solicited commands from the upper layer to the RIL. OnRequestis the function for sending the solicited commands from the upper layer
The following diagram describes the solicited call in Android

Solicited call in Android

Each onRequest call should end with RIL_onRequestComplete. It is to send the response for the previous onRequest and to intimate we are ready for the next command. Refer ril.h for all the solicited commands
Unsolicited commands
These are the commands initiated from the modem to the upper layer. Like, Receive Call /Receive SMS are the commands. The Vendor RIL has to continuously monitor the device for unsolicited command from the modem.
The following diagram describes the unsolicited call in Android

Unsolicited call in Android

Implementation of Vendor RIL
Android is providing the basic vendor RIL with minimum feature set (reference-ril). It is good to start with that reference code. Compile the Vendor RIL as a shared library with the following style
libril-<companyname>-<RIL version>.so
libril – all the Vendor ril library should start with this
Vendor RIL Configuration : Replace the following line in the init.rc file
serviceril-daemon /system/bin/rild
with
serviceril-daemon /system/bin/rild -l /system/lib/libreference-ril.so — -d/dev/ttySx
Commands after “–” will be input for Vendor ril.
Here is sample log of Sending a SMS
D/SMS     ( 1962): SMS send size=0time=1319439322559
D/RILJ    ( 1962): [0312]> SEND_SMS
D/RIL     ( 1814): onRequest: SEND_SMS
D/AT      ( 1814): MUX[primary]: AT> AT+CMGS=14
D/AT      ( 1814): MUX[primary]: AT<>
D/AT      ( 1814): AT> 0001000a814978045948000002c834^Z
D/AT      ( 1814): MUX[primary]: AT< Q: 31,0
D/AT      ( 1814): MUX[primary]: AT< +CUSD: 0,”Your Last Call charge IS Rs  0.5000  AND CURRENT Balance IS  47.8770 AND EXP IS  25/09/21. Love Spl 6 Caller tunes for Jd
D/RILC    ( 1814): Unsolicited Response!!!
D/RILJ    ( 1962): [UNSL]< UNSOL_ON_USSD 0
D/AT      ( 1814): MUX[primary]: AT< “,15
D/AT      ( 1814): MUX[primary]: AT< +CMGS: 219
D/AT      ( 1814): MUX[primary]: AT< OK

For the more information about Android services offered by e-con Systems please visit www.e-consystems.com/android-development-services.asp

What’s new in Android 4.0

 

Since from the Ginger Bread lot has changed. Most of the user experience related changes are well documented by Google here. But there almost no websites out there which gives what is the difference between the GB and ICS at source code level. Here we try to summaries few difference in source code level that we have discovered based on our experience with Android 2.3 (GB) and Android (4.0).
As Google has indicated before ICS has a single set of UI components, styles, and capabilities for phones, tablets, and other devices.

Build Environment

Androids build system hasn’t changed, but various tools’ RAM usage has gone up as they have to deal with more complexity. Some of the native modules are really heavy to link, and operations that work globally on the entire set of public SDK APIs need to deal with massive amounts of data.
ICS needs sun-java6 where GB and previous versions of Android can only compiled with sun-java5

• 6GB of download.
• 25GB disk space to do a single build.
• 80GB disk space to build all AOSP configs at the same time.
• 16GB RAM recommended, more preferred, anything less will measurably benefit from using an SSD.
• 5+ hours of CPU time for a single build, 25+ minutes of wall time
• 20GB of swap

For anything other than the master branch, you’ll need to use Ubuntu 10.04 if you want to be able to build the source code “as is”.
Never had I imagined that ICS would require such heavy-duty machines to build. Folks, it’s time to upgrade your machines!. Most of this data’s are collected based on our experience and from the android building group, Most of the recommendation are by JBQ (jbq@android.com) and other community members.

Target support

Virtual Box Emulator

Android 4.0 supports Virtual Box by default. This is a + for those who want to try build the android stack for x86 targets. Also the android comes up with scripts and make target to easy the task of creation of Virtual box compatible disk’s easy, example is here. use vbox_x86 in lunch.

$ make installer_vdi
$ make android_disk_vdi

Still previous version of Android had support for the vbox, but they were not that much mainstream and x86 architecture were not completely supported. But there was a community driven project named www.android-x86.org, which patched the Android source code heavily to run in x86. But this time it works in as is code of android source. it’s really cool.

• Full_x86 runs in the x86 emulator, which emulates an atom.

$ source build/envsetup.sh
$ lunch full_x86-eng
$ make
$ emulator&

Out of the box, there’s no support for real x86 hardware targets.

• Android ICS has a native support panda board.

Communication/Networking

Concerning the network, it works well at a “system level”. Configure VM in VBox to use a “Bridge” type of virtual NIC, so that Android directly access the network and uses the DHCP server in of PC.

• Wi-Fi Direct – Wi-Fi Direct is a standard that allows Wi-Fi devices to talk to each other without the need for wireless access points (hot spots).
• NFC (Near Field Communication) – Using NFC sharing datas (like contact, photo, song, application, video, or website link, etc..) instantly between device, electronic payments, is just a tapping of ne NFC device to another

But most wide spread Ethernet is not supported in the Android framework still.

Language

Shape Arabic text on a character basis – Arabic Shaping performs basic operations for “shaping” Arabic text. It is most useful for use with legacy data formats and legacy display technology (simple terminals). All operations are performed on Unicode characters

Hardware

• Sensor fusion is the combining of sensory data or data derived from sensors like magnetic filed sensor, gyroscope, accelerometer, etc. The combined result is more accurate, more complete, or more dependable when compared to using them individually [2].
• Mouse pointer support – The good news is that ICS now includes all the necessary code in the framework to support mouse type input devices (with previous versions you had to hack the framework what is done by android-x86 project.

Just rebuild a kernel with the appropriate PS/2 mouse driver.

$ make vbox_defconfig
$ make ARCH=x86 menuconfig

And add the PS/2 mouse driver (“Device Drivers”->”Input device support”->”Mice”->”PS/2 mouse”)

$ make ARCH=x86

The kernel Image will be in arch/x86/boot/bzImage. Replace the prebuilt vbox kernel in your ICS source code tree with arch/x86/boot/bzImage (or create a dedicated device for this)
Rebuild your android_disk.vdi. thats it.

• OrientationSensor – This is a soft sensor, This is a helper provides data for application. This Computes the device’s orientation based on the rotation matrix.
• SecondOrderLowPassFilter – This too is a soft sensor, which provides digital filter functionality for related DSP application.

How to integrate GSM/2G Modem in Android – To establish data Connection

In my previous blog I had shown how Alioth established a data connection and was able to browse the internet. I am going a bit into the details on how we achieved this in this blog.
When I wanted to enable data on the Android Porting that we made to Alioth, I started off with getting it work on Linux first and then moved onto Android .There are some differences in enabling the 2G GPRS for Linux and the steps you need to take for Android
Have a look at the block diagram below


Bottom layers, Layer 1 through 3 is almost same in the Linux. I have enabled the data connection in Linux. Here is a snapshot of bringing up GPRS in Linux (the good old console way !!).



The Top 2 layers are Android Service and Application Layers which has the Telephony manager and the Telephone application as well respectively. These layers do NOT require any change to integrate our modem to Android.
So the changes for Android are concentrated on the following

1. Vendor RIL

2. PPPD Changes for Android.

1.1 Vendor RIL

The Android Open Source Project provides a Radio Interface Layer (RIL) between Android telephony services (android.telephony) and the radio hardware.It consists of a stack of two components: a RIL Daemon and a Vendor RIL. The RIL Daemon talks to the telephony services and dispatches “solicited commands” to the Vendor RIL. The Vendor RIL is specific to a particular radio implementation, and dispatches “unsolicited commands” up to the RIL Daemon
To enable GPRS in Android, we should enable the GSM first. If the SIM_STATE is not ready, the android will not allow the user to enable GPRS from the Application layer. Most of the AT commands used in the sample vendor RIL given by Android will work fine for most of the Modems. But still few commands are specific to the modem which has to be addressed and changed for each modem.
Enabling GPRS and GSM simultaneously requires MUX mode support in the modem and MUX driver to provide multiple virtual channels to RIL.
The reference Vendor RIL uses single physical port for GSM and GPRS. Practically we cannot use that. So we should enable MUX before Vendor RIL starts. The vendor will open two virtual ports for GSM and GPRS respectively.
Solicited commands are the commands from the telephony applications/services to the modem and unsolicited commands are the commands from the modem to upper layers. When the vendor RIL receives a solicited command for DATA connection, it should be routed to the GPRS port and if the command is for GSM, it should be routed to the GSM port. Likewise the unsolicited command read loop should read both the ports (GSM/GPRS) for any new unsolicited command from the modem.
When an enable request received for GPRS with the APN configurations, after sending all the AT commands to enable the GPRS, the vendor RIL has to write all the PPPD configurations to the /etc/ppp/options file and start the PPPD process.
AT Commands to be sent from the Vendor RIL to enable GPRS connection

AT+CGDCONT=1,”IP”,”” // APN name will be one of the parameter for this call

AT+CGQREQ=1 // Set required QoSparams to default

AT+CGQMIN=1 // Set minimum QoSparams to default

AT+CGEREP=1,0 // packet-domain event reporting

AT+CGACT=1,0 // Hangup anything that’s happening there now

ATD*99***1# // Start data on PDP context 1

Here is the sample PPPD options file for Android

/*Sample options file */

<Device name with Path>

user 0

password

unit 0

noauth

nodetach

defaultroute

nocrtscts

ipcp-no-addresses

noipdefault

lcp-echo-failure 4

lcp-echo-interval 60

The final part in the Vendor RIL is monitoring the DATA connection. The vendor RIL should monitor the DATA connection and intimate the upper layer if there is any change in the DATA connection. Set the command AT+CGEREP=2,1 in the modem to enable GPRS notification. Then the modem will generate an unsolicited response “+CGEV” when there is a change in the GPRS connection. If the vendor RIL receives this unsolicited command from the modem, it has to identify the change and intimate it with the unsolicited response RIL_UNSOL_DATA_CALL_LIST_CHANGED. So the Telephony manager service will get to know if there is lose is DATA connection and it will re-establish connection.

1.2 Changes in PPPD

Even though the PPPD layer is almost same as Linux, there are some key changes in the Android PPPD.

1. The PPPD source which is coming with Android will not read its configurations from File. Instead of reading it from file, it will expect it as arguments. All the file operations will be commented out with a macro called ANDROID_CHANGES. We should alter the PPPD to read the PPP options from the file. Because the PPPD options will change whenever there is a change in APN configuration.
2. In Linux, we use chat application and scripts to establish the PPPD connection over GPRS. But CHAT application will not be part of Android based PPPD.
3. In Android, PPPD will be running as a service. So when PPPD lose its connection, it will be restarted automatically.
4. When the device loses the GPRS connection, the PPPD will call the script called /etc/ppp/pppd_down in Linux. But Android PPPD will call /etc/ppp/pppd_down_ppp0. The interface name will be added to the end. Likewise when the PPPD is up, it will call pppd_up_ppp0.

So these changes made my GPRS modem work with Android properly.
I think you are all are interested to know how the telephony would look like. I am working on that blog.. Would come back shortly.

Android Power management

About e-con Systems

e-con Systems, a pioneer in building embedded products has proven expertise in taking Android based products to the market. e-con Systems has been working on Android for over 7 years now and offers Android based development services. e-con has done extensive work on the Android internals and our embedded engineers have an in-depth system level understanding.

Android Power Management

Power management is the most critical thing in any operating system due to the power demand of high end mobile devices. Power management is a technique to conserve power in the expense of latency/performance.
Android Power management built on top of Linux Power Management. Linux Power management is not good enough for a Mobile device. So android keeps the low level power management implementation on Linux and built Android Power management stack on top of Linux PM.
There are two Power management methods in Linux.

1. APM ( Advanced Power Management)
2. ACPI ( Advanced Configuration and Power Interface

Android uses neither. Instead it has its own power management extension called Power Manager. Android added its own core power management driver to its Linux flavour. This module provides low level drivers in order to control the peripherals supported by the Power Manager. Android Power management is mainly application centric. The overall system PM is controlled by the Power Manager which resides on the Android Framework.
Normally Android tries to put the system in sleep mode as soon as possible. Android Applications has to request the Power Manager through “WakeLock” to prevent system going into sleep mode or to keep the peripherals active. If there is no WakeLocks, Power manager will put the system in sleep mode. The following table shows currently supported Android WakeLocks and its effects.

Wake Lock	CPU	Screen	Keyboard
PARTIAL_WAKE_LOCK	ON	OFF	OFF
SCREEN_DIM_WAKE_LOCK	ON	DIM	OFF
SCREEN_BRIGHT_WAKE_LOCK	ON	BRIGHT	OFF
FULL_WAKE_LOCK	ON	BRIGHT	BRIGHT

PARTIAL_WAKE_LOCK

• CPU will be in ON State
• Screen and Keyboard might not be on

SCREEN_DIM_WAKE_LOCK

• Ensures the CPU will be ON
• Let the screen back light and keyboard can go off

SCREEN_BRIGHT_WAKE_LOCK

• CPU will be On
• Screen Back light will be ON – Bright state
• Key board can go off

FULL_WAKE_LOCK

• Full Power state.

Apart from application wake, android does have Kernel wake lock as well. Just to prevent the CPU to goes to sleep mode before it completes some important tasks. Drivers can take a wakelock to do some important tasks like receiving a complete packet from the wireless adaptor.
Also the wake lock can be acquired from native applications through power.c interface.
Just like holding the device not to get into the sleep state, the application can also force the device to force the device to go the sleep state by pressing the power button. The application should have DEVICE_POWER permission to do so.
Upon pressing the power button the application will call the goToSleep API which will force release all the wake locks. This will allow the device to go to sleep state immediately and then /sys/power/state will be set to mem.
e-con Systems optimizes power management to a great extent by working closely with the lower level BSP of the processor and the Android Power States. Visit our Android page here or contact our Android experts – sales@e-consystems.com if you require any support or have any queries.

Make a Free Android Application for Your Mobile

In this post i will teach you how to make a free App of your blog for Android and Nokia Touch Phones. First little description on its importance :
As we all know that Mobile Internet is getting more craze from Internet Users. Many people just use their Mobile Phones to surf internet. An App is a shortcut for a user to search for his requirement. Such as a currency converter app makes it easy for a user to get the results fast either by going to internet explorer and surfing internet to find your currency rate.
I personally build an Android and Nokia Apps of my Blog and it really help me little in my traffic but more than traffic, it gives your Blog a professional Look. If your app receives good stats than you can have an Advertiser to make some revenue from your App. Now let's get started!

Those who have not yet read the Tutorials, please first read them :

1. How To Make Android App
2. How to Make a Nokia App
3. How To Publish Android App in Android Market?
4. How to Make Money By Making Android App?

Building an Android App

1- First of all go to ibuildapp.com and go to Account Login

2- No need to create account, simply Log in through your Facebook account.
3- Click on CREATE APP
4- Continue with Native iPhone/Android App
5- Now you will see a list of different menus. Simply scroll down and select CUSTOM APP and continue.
6- Give your App a name ( Note: This name is shown on Phone. For Example : Camera ). Select Android and continue.
7 - Now the work is very very very easy :) First see the picture below.

8- Choose a Logo, change Background Image ( You can upload your Own ). Now you have Six options as you can see on the left side. It is a Live Demo where you can test your app. Remember, you must have this Six Options, you cannot delete any otherwise you cannot proceed further. You can change the Icons, their names and functions.

To change the icons, click on edit and change the name and icon.
9- To change the functions of these icons, click on any icon on the live demo and than click on CHANGE PAGE TYPE to see the list of different functions. Give a title to your Page Type.

NOTE: When adding Twitter or Photobucket feed, you have to validate it first from feedvalidator . You will get a new URL and you have to use it. 
And in case of RSS Feed Burner URl, u have to add.

http://feeds.feedburner.com/TntByStc?format=xml

Replace TntByStc with your feedburner title. The Red one is extra code to run it on the App

Now i will show you my customized App

As you can see i put the above options. I uploaded my own icons and gave them a unique name and changed their functions from default. The home tab is my feed burner Url. My readers can easily read all the latest news through this app. Also i placed Facebook page, Contact and Website. You can customize it as you want. Just choose from the menus mention in step 9 and place whatever you want. After every change do not forget to SAVE. After completing all the six features, save your app and hit continue.

10 - Next step is your APP Setting. Choose Android option and a beautiful Splash screen. Leave the Advertising option with NO because the other options are useless because if you have to join those ad networks than your app should have huge stats which at time being you do not have because your app is not published on Android Market so leave it with NO but if your app gets good stats than you can get Advertisers as you can see the fourth option ( HTML - create custom ad ). You can place advertiser's banner with his URL. To use Ad Networks, you must publish your App in Android Market ( Further written below about Publishing the app in Market )
11- Save and Continue
12- Now give your app some Information

App logo is that logo which appear on Phone
13- Save and continue to the next step of Notifications. After giving a Notification message, continue to the next and final step.
14- I do not have to explain this step :) it is very easy and you can follow the instructions given to you by them.
YOUR APP IS READY ! But you must try it first with Live Demo From MY APPS link.
Now some important things: If you wish to publish your app to android market, you have to pay a one time fee of 25 dollars but it is not necessary because you can download your app and can upload it on any file hosting and than you can give that link to others. You can test my app on your Android Phones or you can test my App Online

Discover 10 compelling reasons why your next developer security training course

1) Fit Training Around Developer Commitments

Application developers work to incredibly tight deadlines, and it's never feasible to dedicate entire days of work to classroom-based security training. When training is forced upon developers, it can seriously impact project work, creating a conflict of interest for the attending developers.
Thankfully, computer-based security training is designed to accommodate developer workloads. It can be engaged with in short, manageable snippets, and fitted around existing commitments - allowing developers to improve their security knowledge without impacting their day-to-day responsibilities.

2) Improve Developer Engagement

As well as fitting in around existing responsibilities, computer based training can be used to improve how developers engage with their training: using real code examples and practical hands-on training.

3) Reduce Training Costs

Classroom-based training can be expensive. In addition to the costs of hiring a venue, organising transport and finding a speaker, there's the opportunity cost associated with pulling your developers away from several days of billable work. With a more flexible structure, computer-based training can be rolled-out in a much more cost-effective way - allowing training to happen without decimating your development capabilities.

4) Measure Attendance and Analyse Efficacy

Computer-based training offers visibility into crucial performance metrics, from attendance rates through to course completion. It's also easy to gauge the efficacy of each training program, as small end-of-module tests can be used to test a developer's security knowledge, and identify areas that need supplementary training,

5) Self-Paced Learning is More Effective

Traditional classroom-based training forces all participants to engage with the course at the same speed - irrespective of different learning styles or levels of existing knowledge.
Some developers will already be familiar with aspects of the course, and require less time to understand the teaching. For other developers, the course will cover entirely new material, and require additional time to become familiar with the concepts introduced.
Computed-based training facilitates these different learning styles, allowing developers to progress at their own pace, and engage with material as little, or as often, as required.

6) Standardise Core Training

Computer-based training makes it easy to role out essential training to both in-house and remote staff, and easily monitor their attendance and completion rates. As well as improving organisation-wide security awareness, this can be extremely helpful for monitoring essential compliance training (like PCI compliance).

7) Customise Role-Specific Training

Computer based training is extremely modular in nature, making it possible to pick-and-choose only the most relevant training modules. Instead of forcing developers to engage with irrelevant material (like C++ security for a Java developer), or topics they're already familiar with, you can build a customised syllabus to suit the role-specific requirements of each participant.

8) Supplement with Additional Resources

With unparalleled visibility into course completion and pass rates, it becomes easy to identify areas that need supplementary training. Thanks to the flexible nature of computer-based training, it's a simple process to schedule additional training around existing commitments - whether it's a short Q&A with a security expert, or setting up an organisation-specific developer knowledgebase.

9) Improve Knowledge Retention

For developer security training to be effective, completed courses and passed exams need to translate into a real-world reduction in vulnerabilities.
The insights learned in a single classroom-based session can be hard to remember and act upon. Thankfully, the flexible, ongoing nature of computer-based training will help developers practice and apply the principles of their training in the real-world, consulting supplementary resources (like a training knowledgebase) whenever they need to revisit their training.

10) Future-Proof Your Training

The best practices of application security change faster than most classroom-based courses can update their syllabus, and very quickly, important elements of the course's content can become outdated and irrelevant.
Thankfully, computer-based developer security training can be updated much more readily. Outdated modules can be updated remotely, and revisions can be pushed-out on a regular basis - allowing developers to learn how to combat the newest threats and vulnerabilities as soon as they appear.

What is Application Threat Modeling

The most effective way to improve security is to tackle the problem at its source. Though we can't control attacks from malicious third parties, we can control the vulnerabilities and bugs that allow attackers to gain entry and wreak havoc.
To help your organisation improve the security of its applications, we're looking at a straightforward 5-step strategy for identifying and remediating vulnerabilities. Armed with the strategies outlined here, you'll be able to act on potential problems before they cause a serious security breach.

1) Application Threat Modeling

Threat modeling is an exercise to help dev teams understand the potential vulnerabilities and threats an application may encounter in its deployed environment. It's important to start the threat modeling process before coding has begun, and continually re-evaluate the application's risks as it evolves through the software development lifecycle (SDLC).
This process offers a systematic and organised way to identify and track potential vulnerabilities. By ranking threats, limited development resources can be used in the most effective way possible; ensuring that effective countermeasures are chosen to combat the biggest perceived threats.
The threat modeling process can be broken-down into 3 simple stages:

1. Decomposing the application.
2. Identifying and ranking threats.
3. Identifying suitable countermeasures.

To learn more about application threat modeling, read our blog post: What is Application Threat Modeling?

2) Security Design Reviews

Security design reviews are designed to cast a critical eye over the security of an application's structure. Application architecture, deployment infrastructure and design at each tier of development are analysed for vulnerabilities and bugs. The more frequently these code reviews are conducted, the easier it becomes to identify potential problems as soon as they appear. As well as being easier to fix, any problems that are identified early in the SDLC are significantly cheaper to remediate than those identified after launch.
Though it isn't always possible to budget for regular formal code reviews, it's often easier to incorporate an informal design review into the development process. Pair programming offers an efficient and cost-effective way of identifying early stage problems; and does so in a collaborative (and even competitive) manner.
To learn more about the importance of regular code reviews, read our post: Why Organisations Need to Start Doing More Frequent Code Reviews.

3) Developer Security Education

A developer's primary role isn't to ensure application security - it's to create fast, functionality-rich code, quickly and to budget. There are myriad ways for a developer to achieve their objectives and create functional code, but without education into the best practices of secure coding, there's no guarantee their code will be secure.
To minimise the number of vulnerabilities and bugs that make it into a finished product, it's important to stem the problem at the source: and help developers create secure code. The exact nature of secure code will vary by their role and specialism, but thanks to online eLearning courses, it's easier than ever to tailor-make a syllabus that fits their needs. Whether your developer is using PHP or C++, it's possible to create an engaging and effective security syllabus to teach them about the best practices of secure code.

4) Penetration Testing

Penetration testing allow you to test-out the security of your application, and model the type of attacks it might encounter after release. The types of attack vectors used by the testers (for example SQL injection or cross-site scripting) allows you to identify the most at-risk points of entry into your application. These can then be used to prioritise further testing and redevelopment, allowing you to plug-up the biggest holes in your security before release.
Penetration testing is also invaluable for improving the security awareness of developers. Seeing how their code is interacted with in real-life, and understanding the vulnerabilities that allowed a third-party to gain access to the application, will help devs to improve their coding, and avoid creating the same loopholes in the future.
To learn more about the role of penetration testing in secure application development, read our blog post: What is Penetration Testing, and Why is It Important? 

5) Final Security Review

The final security review acts as a sanity check prior to release. It provides the development team with an opportunity to reflect on their previous security findings, and ensure that all the problems they've identified have been remediated to a suitable degree.
If each of the prior steps have been followed, the dev team should be able to rest easy - safe in the knowledge that the security of their application has been tested throughout the software development lifecycle. When release day finally comes, this should minimise the number of problems encountered, and significantly reduce the costs of issuing expensive post-release fixes and patches.

How Secure Code Reduces The Risk of Inevitable Attacks

Attacks on your organisation aren't just possible anymore. They're inevitable.
You're at risk whether you're part of a small company with a basic Wordpress website and your files stored in the cloud; or a large enterprise using tens of interconnected SaaS products, internally developed applications and computer networks.
News of vulnerabilities spread amongst hacker communities faster than ever, and there's an ongoing race between security companies and attackers that we're not getting any closer to winning.
According to a recent report from CyberEdge Group, 70% of organisations experienced a successful cyberattack in the last 12 months. Of those attacked, 22% experienced at least 6 successful attacks.
In this post I explain why traditional approaches to security fail, and explain why helping developers to write more secure code is the best way to reduce risk.

The Traditional Security Approach

Security within many organisations is still treated like a box ticking exercise. An audit's coming up, and it's important the company passes, or it will face penalties. As a knee-jerk reaction to this, you buy security software and hardware, like firewalls, intrusion prevention systems  and scanners.
Whilst this approach often worked in the past, it's not effective in isolation anymore. Most organisations build their own software, in addition to using a large number of externally developed applications. Whilst there's not much you can do to prevent vulnerabilities in the software you buy (beyond learning how to choose secure vendors, and making sure security awareness is an organisation-wide priority), there is something you can do to reduce the risk of inevitable attacks on the software you develop in-house.

Develop More Secure Code

According to a 2013 Global Information Security Workforce Study, 69% of security professionals stated that application-layer vulnerabilities were a primary threat to their organization. Another report from SANS learned that just 10% of organisations secure their business applications before and during development. This represents a huge opportunity to reduce the number of successful attacks against your organisation.
Application security is most effective when it's incorporated early in the software development lifecycle. Data indicates that it's 30x more expensive to fix a vulnerability during post-production than during the design, requirement identification and architecture stage. The earlier you can prevent vulnerabilities in the software development lifecycle, the better.
Reducing the cost of vulnerabilities is therefore best achieved in two ways:

1. Training developers in security best practices, so that they don't design or develop insecure software in the first place. 
2. Providing developers with security tips and warnings within their development environment, to eliminate vulnerabilities as they're introduced to code. 

If you want to reduce the risk of inevitable attacks on your organisation, it's fundamental that you do both. Security hardware and software reduces risk; but they're fallible plasters covering up holes that wouldn't have made it into your software if security was taken seriously earlier in the software development lifecycle.

6 Reasons All Application Developers Need a Training Knowledgebase

There's a missing link in your application security: a training knowledgebase. To help improve the efficacy of your security training roll-out, I'm exploring the purpose of a knowledgebase - and looking at six reasons for implementing one in your organisation.

1) It's Everything Secure Developers Need, In One Place

There's more to effective security training than classroom sessions and online tests. For developers to effectively engage with training, and learn to apply its principles in a real-world setting, they need a way to revisit their training. They need access to a resource that compiles all of the advice, insights and examples of their security training in a single, easy-to-access place.
A security knowledgebase (like our own Team Mentor) provides easy access to thousands of security artifacts. From advice on application design, to individual examples of the latest vulnerabilities, it provides a one-stop shop for developers to brush-up on their training.
When a cross-site scripting or buffer overflow problem emerges, it provides developers with immediate access to the information they need to effectively remediate. There's no need to pore over a Google search, or scour development forums for advice - and developers can learn about each vulnerability, and its countermeasures, at the click of a button.

2) It Offers Role-Specific Advice

Even if developers are able to learn about a vulnerability from an internet search, there's no guarantee the solution will be relevant to their particular role. Remediation advice needs to be specific to a developer's individual role, whether they're an architect or a Java developer. Whilst generic advice may help developers to understand their problem, it'll do nothing to help them effectively remediate it.
A training knowledgebase makes it possible to search for this type of role-specific information. As well as indexing content by individual vulnerability and bug, it makes it possible to search by role and specialisation - allowing developers of all stripes to find information specific and helpful to their individual role.

3) It's Customisable to Your Team's Standards

Many organisations and development teams have their own set of internal standards and development rules. When a vulnerability appears, these rules may prevent developers from following the best practices detailed in security courses and online advice. This can often mean that otherwise useful information can't be used to remediate - leaving developers with no recourse for fixing vulnerabilities.
Thankfully, a training knowledgebase should be more than a simple respository of information. Thanks to its customisable nature, the information and best practice outlined in a training knowledgebase can be customised to the unique needs of the development team. It makes it easy to centralise development standards; and where these standards contradict remediation advice, fellow team members can explain how they've overcome the problem in the past, and detail their own solutions. This makes it possible to create an archive of successful remediation strategies, unique to the rules and standards of each development team.

4) It Improves Developer/Security Communication

Many organisations struggle with the security team/development team dynamic. Without security education, development teams find it difficult to respond to the vulnerabilities and bugs identified by security's testing. Without the ability to remediate, the same problems appear the next time security test - leading to growing friction between the two teams.
With a developer knowledgebase, security teams can quickly and easily point development teams to the information they need to remediate the problems detected by security. Instead of dumping a damning report on their desk, and telling the developers that their baby's ugly, security can soften the blow - providing actionable advice for fixing problems, and helping both teams to improve the results of the next test.

5) It Gives Developers Real Code Examples

Tools like Quick Scan and Fortify can be helpful for identifying problems, but in most instances, the remediation advice they offer isn't great. Without role-specific information, and actionable advice to follow, it's extremely hard for developers to use their security knowledge to fix real-world problems.
Thankfully, the best developer knowledgebases will actually integrate with these static code analysers. Tests can be run, and when problems are identified, developers will be able to find real-time solutions to problems, as they appear. As well as providing general advice around each problem, they'll be able to use actual code examples to streamline the remediation process.
As well as saving development and security teams a ton of time, this makes it easier than ever for developers to learn from their mistakes - identifying problems as they appear, and learning the code needed to prevent these problems from recurring.

6) It Improves the Efficacy of Security Education 

Organisations everywhere understand the growing need for application security, and many even choose to roll-out an application security training course. However, the lessons and insights learned by developers will fade over time - and a few weeks and months down the line, there's no guarantee that developers will be able to apply their knowledge to the real-world.
Security education is the key to finding and solving vulnerabilities early in the SDLC; and a training knowledgebase is a crucial component of making that education as effective as possible. By providing developers with an easy-to-access repository of effective, customisable security knowledge and detailed examples, you can ensure that every penny of your security training investment is used as effectively as possible.

2G, 3G, 4G, 4G LTE, 5G – What are They?

Quite simply, the “G” stands for Generation, as in the next generation of wireless technologies. Each generation is supposedly faster, more secure and more reliable. The reliability factor is the hardest obstacle to overcome. 1G was not used to identify wireless technology until 2G, or the second generation, was released. That was a major jump in the technology when the wireless networks went from analog to digital. It’s all uphill from there. 3G came along and offered faster data transfer speeds, at least 200 kilobits per second, for multi-media use and is still the standard for wireless transmissions regardless of what you hear on all those commercials. It is still a challenge to get a true 4G connection, which promises upwards of a 1Gps, Gigabit per second, transfer rate if you are standing still and in the perfect spot. True 4G on a wide spread basis may not be available until the next generation arrives. 5G?

What are the Standards of the G's

Each of the Generations has standards that must be met to officially use the G terminology. Those standards are set by, you know, those people that set standards. The standards themselves are quite confusing but the advertisers sure know how to manipulate them. I will try to simplify the terms a bit.

1G – A term never widely used until 2G was available. This was the first generation of cell phone technology. Simple phone calls were all it was able to do.

2G – The second generation of cell phone transmission. A few more features were added to the menu such as simple text messaging.

3G – This generation set the standards for most of the wireless technology we have come to know and love. Web browsing, email, video downloading, picture sharing and other Smartphone technology were introduced in the third generation. 3G should be capable of handling around 2 Megabits per second.

4G – The speed and standards of this technology of wireless needs to be at least 100 Megabits per second and up to 1 Gigabit per second to pass as 4G. It also needs to share the network resources to support more simultaneous connections on the cell. As it develops, 4G could surpass the speed of the average wireless broadband home Internet connection. Few devices are capable of the full throttle yet. Coverage of true 4G is limited to large metropolitan areas. Outside of the covered areas, 4G phones regress to the 3G standards. We have a ways to go. For now, 4G is simply a little faster than 3G.

4G LTE– Long Term Evolution – LTE sounds better. This buzzword is a version of 4G that is becoming the latest advertised technology but still not true 4G as the standards are set. When you start hearing about LTE Advanced and WIMAX Release 2, then we will be talking about true fourth generation wireless technologies because they are the only two formats realized by the International Telecommunications Union as True 4G at this time.

WiMAX - Worldwide Interoperability for Microwave Access – should be capable of around 40 megabits per second with a range of 30 miles. It is one of the closest technologies to meet the standards of true 4G and as it develop should surpass the 100MB/second which is the 4G standard. Mobile WiMAX allows the use of high speed data transfers and is the main competition for the 4G LTE services provided by cellular carriers.

5G - There are rumors of 5G being tested although the specifications of 5G have not been formally clarified. We can expect that new technology to be rolled out around 2020 but in this fast-paced world it will probably be much sooner than that. Seems like a long ways away but time flies and so will 5G at speeds of 1-10Gbps.

The major wireless networks are not actually lying to anyone about 4G, they simply stretch the truth a bit. A 4G phone has to comply with the standards but finding the network resources to fulfill the true standard is difficult. You are buying 4G capable devices but the network is not yet capable of delivering true 4G to the device. Your brain knows that 4G is faster than 3G so you pay the price for the extra speed.

How to Close the Gaps in Your Application Security Program

Historically, IT security was primarily focused on network and endpoint security. Now, as the best practices of security begin to catch-up to the mounting threats posed by new technology, application development and the SDLC are suddenly within security's remit.
Whilst many organisations understand the need for improved application security, few are implementing their programs in an efficient and effective way. As a result, the vast majority of application security programs find themselves riddled with gaping holes - holes that can be readily exploited by software vulnerabilities and malicious third-parties.
To help you plug some of the most common gaps found in application security programs, we're looking at three strategies you can take action on today.

1) Create Role-Specific Policies, Not Just General Policies

Codified security policies are an important first step in developing application security. However, creating a standalone policy isn't enough to help developers and security teams translate intention into action. In order to mediate the distance between policy and practice, it's essential to create role-specific versions of crucial security documentation.
For example, many organisations create controls that dictate the need to 'protect cardholder data', 'follow industry best practice', or even 'prevent applications from being vulnerable to the OWASP Top 10 threats'. These types of high-level policies do nothing to help on-the-ground security implementation.
To prevent applications succumbing to OWASP's top vulnerabilities, a developer has to go through a whole plethora of steps:

• Identifying which threats to prioritise (e.g. injection threats)
• Isolating and prioritising individual threats (e.g. SQL injection)
• Learning about suitable countermeasures, and identifying which are most relevant.
• Discovering how to implement these countermeasures in a specific development language.

Developers, security teams, customer-facing staff and the C-suite will all approach policy and implementation from different perspectives. For policy to translate into practice, it has to be developed and distributed in a way that makes sense to people in each distinct role.

2) Create a Feedback Loop Between Security and Developers

These overly-generalised security policies create a serious disconnect between two essential components of application security: the development team, and the security team.
Without a shared understanding of their respective roles and responsibilities, it's extremely difficult for the two teams to engage in an effective way. In many organisations, this creates an all-too familiar problem: security throwing a context-less report at the dev team, and the dev team struggling to make sense of false positives and vulnerabilities. It's this disconnect that creates security's bad reputation in many organisations - and prevents two crucial security advocates from following effective policy.
To prevent this problem, security and development teams need to be less centralised - using a formal feedback loop to discuss security findings, and outline ways to resolve them. In many instances, developers simply lack the knowledge required to remediate against vulnerabilities. In other cases, security struggle to make sense of the reporting tools, and end up generating a ton of recurring false positives (something which heavily contributes to the problem of shelfware).
By facilitating open discussion between teams, and mandating ongoing security training, both teams will be empowered with the knowledge and authority necessary to improve security.

3) Ask Technicians to Assess the Maturity of Your Application Security Program

The application security maturity model is a valuable tool for assessing your efficacy in converting policy into practice. However, many organisations take an unintentionally blinkered approach to assessing their application security - turning exclusively to their directors and executives for insight. However, directors aren't always best placed to analyse security - and often look to very different hallmarks of efficacy than those a developer would turn to.
To highlight this, a full 75% of executives believe their application security is at a mature state - proactively dealing with potential vulnerabilities before they become a problem. In stark contrast, only 23% of technicians at the same organisations agreed. Whilst 2/3 of budget holders thought their security investment was bearing fruit, only 1/4 of on-the-ground staff agreed.
This is perhaps the most important point to raise: to close the gaps in your application security pogrom, you first have to be aware of them. Security is an ongoing, iterative process - and a mechanism for constantly assessing and reassessing potential threats, and your response to them, is a vital part of improving your organisation's security.

3 Things Secure Application Developers Need From Your Security Team

Struggling to improve your application security?

In most organisations, there's a serious disconnect between developers and security. Both teams work hard at their respective roles, but without the time and infrastructure necessary for effective collaboration, a significant amount of bugs and vulnerabilities make it into finished applications.
To help you improve your application security, and reduce the costs of remediation, I'm looking at 3 things secure developers need from your security team.

1) Clear Communication

Regular security tests are an essential tool for improving application security; but for most developers, security reports are complex, jargon-filled, and difficult to understand. For developers to take action on a test, and reduce vulnerabilities, they need security to provide context to their findings.
Whether it's a buffer overflow problem or a case of SQL injection, most developers lack the security team's specialised knowledge. Before any remediation can take place, the security team need to help developers understand the problems they've found, and offer advice on which problems need to be tackled first.

2) Remediation Advice

In most cases, the remediation advice offered by static testing tools leaves a lot to be desired.
Application vulnerabilities can be complex, especially when remediation has to abide by the organisation's own unique development standards. Without security education, few developers will have the knowledge necessary to remediate against vulnerabilities. Without the education or resources to solve a problem, vulnerabilities are left unchanged - and the next time the application is tested, the same problems reappear. 
Wherever possible, security teams need to offer explicit remediation advice to developers. Their advice needs to be role- and development language-specific, and contain real code examples for developers to follow and learn from.
It's fair to say that few security teams will have the time or capacity required to provide explicit remediation advice alongside their test findings. In these instances, it's vital to establish a training knowledgebase - a centralised repository of security artifacts, insights and education.
As well as allowing developers access to information and education whenever they need it, a knowledgebase allows the security team to point developers to actionable, role-specific remediation advice and real-world examples - without wasting time on epic emails and in-depth advice.

3) Empathy

For most developers, security simply isn't a priority.
In the majority of organisations, developers are hired to create functionality-rich code, as quickly and cost-effectively as possible. They have to meet incredibly tight deadlines, and constantly improve and iterate upon their code in the process.
They get judged on the efficacy of their code, and not its security: and any time given to security education or code review is time that isn't spent serving their primary objectives.
Security teams need to understand the challenges faced by developers. They don't 'overlook' security out of stubbornness, or choose to ignore the security team's feedback: they simply don't have the time or resources to make security a priority.
Thankfully, security education and eLearning courses can help developers overcome these challenges. With a bit of empathy from the security team, the dynamic between security and development can be improved - and application security can be completely transformed.

10 actionable ways to improve the security of remote working

We're looking at 10 actionable ways to improve the security of remote working, and protect confidential data on personal devices.

1) Develop a Bring Your Own Device Policy

To address (and remedy) the problems associated with Bring Your Own Device working, it's essential to create a formal and codified BYOD policy. This policy should raise awareness of the problems associated with remote working, and outline the procedures employees need to follow to secure their devices; whilst being flexible enough to adapt in response to employee feedback.
To learn more about developing your own Bring Your Own Device policy, read our blog post: The Impact of BYOD on Organisation Security

2) Educate About the Best Practices of Password Security

A password is a crucial first layer of security on a personal device. Whilst most people understand the importance of passwords, few understand the best practices of effective password security. It's important to educate employees on password security, and create a set of codified minimum standards to ensure that passwords are as effective and secure as possible.

3) Discuss Physical Threats, As Well As Remote

Many of the criticisms levied at the Bring Your Own Device trend concern the remote security of personal devices. However, remote security is only half of the problem - and physical vulnerabilities, from lost and stolen devices, represent a serious risk for organisations.

4) Address the Risks of Phishing and Social Engineering Attacks

In particular, the problem of phishing and other social engineering is growing in prevalence. Fake login pages on social media sites, emails with malicious attachments and even fraudulent phone calls are all used to gain access to personal devices and sensitive information.
Thankfully, education is the most powerful tool for combating these problems - and by raising awareness of the common tactics employed by malicious third-parties, your workforce can reduce the risks of succumbing to them.

5) Enroll in ‘Find My Device’ and Remote Wipe Services

In the event of a stolen or lost device, it's important that your organisation can reduce the risks of sensitive data falling into the wrong hands. Thankfully, services exist that can identify the location of lost devices, and if necessary, erase all of the data from them - removing all sensitive and confidential information from the device.

6) Clarify Ownership Over Apps and Data

However, erasing data on a personally-owned device brings with it its own set of problems. Though confidential business information will be erased, so too will a plethora of personal information and applications. It's important to discuss where authority lies in these situations - and set expectations for the potential loss of personal data.

7) Decide If Any Apps Should Be Banned

Not all applications are created to the same standards of security. If popular applications suffer from a well-known vulnerability, it makes sense to prevent employees from installing these applications onto a device loaded with confidential data.

8) Enforce Your BYOD Policy

Many organisations create a Bring Your Own Device policy, but due to a lack of support, find themselves simply paying lip service to its principles. Your policy needs an executive mandate, with compliance regarded as an essential responsibility of any employee choosing to use a personal device.

9) Consider Switching to a CYOD Policy

Instead of creating a retroactive security policy, and attempting to secure an existing device, Choose Your Own Device (CYOD) allows organisations to be proactive - acknowledging the benefits of remote working, and taking ownership of the security risks involved.
By offering a range of pre-approved devices for employees to use, security features can be built into the device from day one - and ownership over data and applications remains within the remit of the organisation.

10) Create an Exit Plan

When an employee leaves the company, they have a right to take their personal devices with them - but what happens when confidential corporate data is stored on their device?
An exit plan will detail the steps employees need to go through to ensure the removal of sensitive information - and by making these expectations clear from day one, the interests of both employee and organisation will be protected.

6 Essential Components of End User Security Training

No matter how secure your software, or how comprehensive your security policy, your organisation is put at risk each and every day. The culprit? Your employees: the people who use your software and implement your security policy.

To help reduce the human risk to security, I'm looking at 6 crucial components of an effective end user security training program.

1) Phishing Awareness

Phishing attacks harness the power of social engineering to trick end users into relinquishing sensitive information and login credentials. Whilst many phishing attacks rely on brute force (sending thousands of emails in the response of one or two responses), hackers are increasingly using 'spear phishing' attacks - faking personalised communication from trusted sources, in order to gain access to secure services and data.
Spear phishing attacks are much harder to identify and avoid, so it's essential to raise awareness of the common characteristics and sources of phishing, including:

• Email
• Messaging apps
• Intranet
• Social media
• Web browsers

Learn more: 5 Ways Organisations Can Reduce the Risks of Phishing

2) Password Security

Passwords are the first layer of defense in many security systems, but unfortunately, they aren't infallible. Without the help of a password management system, it's left to the end user to choose a secure password and commit it to memory.
As Adobe's famous data breach can testify to, this is easier said than done - with 5.96 million of their leaked login credentials appearing in a list of the top 100 most commonly used passwords.
It's important to educate your users about the best practices of password security, and implement mandated measures to ensure that secure practices are always followed.
Learn more: How to Improve Organisation-Wide Password Security

3) Shadow IT

Despite an organisation's best efforts, it's commonplace for the end users of an IT network to take it upon themselves to install and use unapproved software applications. This practice is known as Shadow IT, and with the growth of the Bring Your Own Device trend and cloud-based applications, it's easier than ever for employees to download and use insecure software.
Learn more: Is Shadow IT a Threat to Your Organisation?

4) BYOD

The growing shift towards Bring Your Own Device working pose a unique set of risks. In order to protect your sensitive information, whether it's stored locally on a desktop PC, remotely in a cloud storage account, or accessed on a tablet or smartphone, it's important to educate end users about the best practices of secure remote working.
This includes implementing a BYOD policy, preventing local storage of secure corporate data on personal devices, and protecting data-in-motion with some form of encryption.
Learn more: 10 Ways to Improve Bring Your Own Device Security

5) WiFi Security

Whether employees work from home, the office, or even a local coffee shop, it's important for end users to understand the risks associated with wireless networks, particularly "evil twin" and "war driver" attacks.
"Evil twin" attacks create fake WiFi networks with the same name and credentials as legitimate wireless networks. When an end-user connects to the fake network, the attacker can capture sensitive information and login credentials.
"War driver" attacks compromise non-secure wireless networks, and intercept any information being exchanged in the network. This can be problematic when end users connect to your organisation's non-secure wireless networks (like a Guest WiFi account) instead of a password protected network, and use them to access and transfer sensitive information.
Learn more: How to Reduce the Risk of Common WiFi Security Threats.

6) PCI Compliance

End users play a crucial role in ensuring compliance with essential regulations and legislation. Compliance with  Digital Security Standards is required of all organisations that process debit and credit card information; and with each job function and role in your organisation engaging with payment information in a different way, it's essential for every end user to understand the principles of PCI DSS.

5 Ways Organisations Can Reduce the Risks of Phishing

Phishing is a big problem for organisations, for two simple reasons: it's easy to do, and it works.
It's relatively easy for hackers to send hundreds of thousands of emails, to employees at hundreds of organisations. It's low risk and low cost, and without proper security in place, it can take as little as a single click from an unwitting employee to give hackers access to highly sensitive and highly valuable data.
So, to help your organisation defend itself against the risks of serious attacks and data breaches, I'm outlining 5 ways you can take action against phishing.

1) Roll-Out a Security Awareness Program

Phishing is so problematic because it targets the end-user: people who typically have little-to-no security knowledge. Whilst there's no silver bullet for the problem, educating your employees about the risks and hallmarks of phishing attacks can significantly reduce the likelihood of a serious data breach from occurring.
Phishing attacks typically use a handful of tactics to get employees to part with login credentials, most commonly leveraging emails, web browsers and social media sites. Security awareness training will help your employees to effectively scrutinise suspicious communication from each of these channels, and make it easier to identify the signs of a potential phishing attack - whether it's a suspicious email attachment, an unsolicited friend request, or an unexpected browser redirect.

2) Use Layered Security

Your organisation's sensitive data should be protected by several layers of security, so that in the event of a successful phishing attack, malicious third-parties are unable to gain access to the entirety of your secure systems. Secure log-in information and password security should function only as the first layer of defense, supported by email security, data encryption, anti-virus software, user monitoring, priveleged access protocols and other forms of layered security.

3) Keep Anti-Virus, Anti-Malware and Anti-Spyware Up-to-Date

Whilst anti-virus, anti-malware and anti-spyware software won't eradicate all phishing attempts, they will help to significantly reduce the volume of suspicious emails and attachments making it into the hands of the end-user. Crucially though, security software shouldn't be approached with a set-it-and-forget-it mentality. Most applications require some form of manual oversight, and function best with regular maintenance of their parameter settings; changing thresholds and sensitivity to respond to the types of phishing attacks experienced.
The same concepts apply to all of an organisation's applications and operating systems. All forms of software and infrastructure need to be regularly maintained, and updated and patched to keep them up-to-date with the latest vulnerabilities and threats.

4) Get Smart with Password Security

Almost all organisations use some form of password security; but few implement passwords in a secure way. As well as outlining and enforcing the best practices of password security, it's important for organisations to use some kind of password expiration date on all login credentials.
In doing so, the damage of successful phishing attacks is limited - making stolen passwords obsolete, and preventing malicious third-parties from gaining permanent access to your secure systems. This type of security works even when phishing attacks go undetected, and when combined with two-factor authentication, can dramatically help reduce the damage caused by phishing.

5) Test Your Security

In the same way that penetration tests are used to test application security, it's important to periodically assess your organisation's phishing defences. Whilst eLearning and periodic testing play a crucial role in this, some organisations choose to go a step further, and use fake phishing emails to assess their employee's security knowledge. In doing so, it becomes possible to continually assess the security knowledge of your employees, and identify areas which require additional training in order to further improve your organisation's security.

What's The Difference Between Hashing and Encrypting?

Hashing and encrypting are two words that are often used interchangeably, but incorrectly so.
Do you understand the difference between the two, and the situations in which you should use one over the other? In today's post I investigate the key differences between hashing and encrypting, and when each one is appropriate.

Hashing

What is it?

A hash is a string or number generated from a string of text. The resulting string or number is a fixed length, and will vary widely with small variations in input. The best hashing algorithms are designed so that it's impossible to turn a hash back into its original string.

Popular Algorithms

• MD5 - MD5 is the most widely known hashing function. It produces a 16-byte hash value, usually expressed as a 32 digit headecimal number. Recently a few vulnerabilities have been discovered in MD5, and rainbow tables have been published which allow people to reverse MD5 hashes made without good salts.
  
• SHA - There are three different SHA algorithms -- SHA-0, SHA-1, and SHA-2. SHA-0 is very rarely used, as it has contained an error which was fixed with SHA-1. SHA-1 is the most commonly used SHA algorithm, and produces a 20-byte hash value.
  
  SHA-2 consists of a set of 6 hashing algorithms, and is considered the strongest. SHA-256 or above is recommended for situations where security is vital. SHA-256 produces 32-byte hash values. 

When Should Hashing Be Used?

Hashing is an ideal way to store passwords, as hashes are inherently one-way in their nature. By storing passwords in hash format, it's very difficult for someone with access to the raw data to reverse it (assuming a strong hashing algorithm and appropriate salt has been used to generate it).
When storing a password, hash it with a salt, and then with any future login attempts, hash the password the user enters and compare it with the stored hash. If the two match up, then it's virtually certain that the user entering the password entered the right one.
Hashing is great for usage in any instance where you want to compare a value with a stored value, but can't store its plain representation for security reasons. Other use cases could be checking the last few digits of a credit card match up with user input or comparing the hash of a file you have with the hash of it stored in a database to make sure that they're both the same.