Mobile Network Operators face unique security challenges

Mobile Network Operators face some particularly unique challenges. They have all the normal concerns of a business dependent on IT, plus the added requirement that they must secure the network while making it widely available to their customers and the customers of other operators without compromising the infrastructure, their peers, or the end users and their personal data.

These challenges are set in an environment of changing technology, business models, and industry structure. Couple this with the fact that of outages cost big money, and mobile communications are often highly personal, the stakes are very high for MNOs.

To assist fellow security professionals working in the Mobile sector, 360is have come up with our list of the most common mistakes made by MNOs.

Mistake 1. Over Integration / Under Segregation

One of the tenets of good information security is the separation of networks of differing levels of trust. Unfortunately this practice is easily eroded or rendered ineffective by over-integration of different functions onto a single hardware platform or software infrastructure. Over integration amplifies the effects of any individual security failing .

One sure sign of over integration is that you have difficulty in drawing up truly separate network diagrams for subscriber, management, and telemetry functions. Conversely, if you can easily move data and conduct interactive sessions between those 3 networks without a defined intermediate gateway or bastion stage in the process, this is also a bad sign.

Mistake 2. Misplaced Faith In Encryption

The second mistake and the first are often found together. Software and Hardware vendors have tended to treat encryption as a sort of magical security whitewash, to be sprayed liberally over everything, disguising unsightly flaws or cracks in the architecture. Encryption (implemented properly) is a great way to ensure confidentiality of communications on a shared network but historically it has suffered from poor implementation; weak random number generation, flawed protocols, and endpoint vulnerability.

In practice attackers rarely focus on the encrypted tunnel itself when there are far easier pickings to be had among the authentication system, the tunnel endpoints, and intermediate proxies.

Mistake 3. Not Considering Atypical Behavior

Once handsets were dumb. They had no user-settings, no expansion, and no ability to run code other than their Firmware. Users could make voice calls and send SMS, life was simple for the MNO. Today a "handset" can be a phone, a smart phone, a laptop, even a server. Services extend to voice, SMS, Internet, Corporate VPN, i-mode style portals, and hosted applications like BlackBerry.

MNO's expend huge amounts of time and money testing all these handsets with all these services to ensure a positive experience for their subscribers, but somehow in the testing... security gets ignored. Just because handsets are normally allocated addresses by DHCP and browsers are configured to use your proxy, doesn't mean an attacker with a laptop will follow "regular user behavior". Does your security testing take this into account? Claiming "You can't do that with our (handset/registration process/portal)" is not a very effective defense for your network.

Mistake 4. Incorrect Trust Models

Crashing these mistakes into one-another is becoming a theme. Following on from atypical behavior we come to the problem of trust among network elements, users, and their traffic. The reason why behavior is such a problem is that mobile networks often have their trust models wrong.

A trust model that relies on the handset to behave itself is as bad as those that rely on the user to behave himself. MNO security staff should be very wary of trusting source addresses, the interface traffic appears on, or any credentials passed by systems they do not exclusively control. If somebody says "It's a walled garden, we don't need to worry" you are probably already making mistake 4.

Mistake 5. No consideration of Modes Of Failure

Not planning for the inevitable failure of one or more parts of your security architecture is foolish. Sooner or later a configuration slip-up, a careless/malicious insider, or a new bug in your systems will cause one of your security mechanisms not to work. Does it fail-safe? Are you pro-active in checking all the careful steps you took to avoid mistakes 1-4? What is the extent of your exposure if any one of these mishaps occurs? Vendors hate to answer the question "what about when it doesn't work?" but you as security architects for your MNO must accept such eventualities as inevitable and plan for the worst.

Conclusions

The challenges faced by MNOs are similar to those faced by SCADA users a few years ago. They stem from the increasing pervasiveness of IP, the evolution of handsets from "dumb" single purpose devices to more flexible, complex systems, and the increased variety of services offered to subscribers. In an industry where "air gaps" are a myth, we have found many MNOs making the same mistakes as their cousins in the utility sector.

Equipment vendors must shoulder part of the blame for vulnerability in mobile networks, many of their systems are based on unhardened main-stream Operating Systems. However, MNOs themselves do not escape criticism.

It is common for entire networks to be sourced from a single vendor, radio-side and fixed-side, but this is no excuse for abdicating responsibility for operational security. That burden rests squarely with the operator.

http://www.securitypark.co.uk/security_article261518.html

CCNA -- Cisco Certified Network Associate Study Guide: Exam 640-802

Cisco networking authority Todd Lammle has completely updated this new edition to cover all of the exam objectives for the latest version of the CCNA exam.

ISO OSI reference model

A comprehensive tutorial is available at tutorialsweb on ISO OSI model. OSI model is the basic building block of CCNA certification preparation, and it is highly required that a CCNA aspirant has a solid understanding of different layers of OSI model. The contents of the tutorial are given below:
The OSI (Open Systems Interconnection) Model
Information Exchange Process
Relationship between the OSI Model and Networking Devices
Repeaters, Bridges, Routers, Gateways and other network components
Glossary of Networking Terms
Read complete tutorial on ISO OSI model for CCNA preparation.

CCNA ICND2 Practice Tests

SimulationExams.com, recently released CCNA ICND2 (Interconnecting Cisco Network Devices 2) practice tests. ICND2 exam counts toward CCNA certification awarded by Cisco Systems®. CCNA ICND2 isintended for candidates who have experience in configuration and troubleshootingof Cisco networking devices.. The practice tests offered by SimulationExamsprovide a simulated test environment for candidates before appearing for thecertification exam.
The advantages of a simulated exam are:
Ability to gauge one's preparedness to take actual certification exam
To strengthen weak areas
To familiarize oneself with actual exam environment (such as timed test, lab practice, relevant practice questions, etc.)
CCNA ICND2 is one of the two qualifying exams available to candidates pursuing a two-exam option for Cisco Certified Network Associate Certification. To achieve CCNA, one need to pass both CCENT (also known as CCNA ICND1), and the CCNA ICND2 exams. Alternatively, one can obtain CCNA certification by passing a single exam, 640-802.

Sub Net Table

Bits	1	2	3	4	5	6	7	8
Subnets	0	2	6	14	30	62	126	254
Mask	128	192	224	240	248	252	254	255
Class A	/9	/10	/11	/12	/13	/14	/15	/16
Class B	/17	/18	/19	/20	/21	/22	/23	/24
Class C	/25	/26	/27	/28	/29	/30

		Max Networks	Class Number /First octet	Max Host
Class A	255.Mask.0.0	127	1-127	16777214
Class B	255.255.Mask.0	16,383	128-191	65534
Class C	255.255.255.Mask	2,097,152	192-223	254

Privacy Policy

Your privacy is of utmost importance to us here at my site. Rest assured that any information you provide will only be used in accordance with this privacy statement.This policy may be updated or changed anytime and we encourage you to review it whenever you visit the site to make sure you understand how any personal information you provide will be used.

Collection and Use of Information

We collect personally identifiable information such as names and email addresses only when voluntarily submitted. These information are used merely to fulfill a specific request, for example, to post a comment on our blog, to create an account in our Forum, or to subscribe to our mailing list. All emails and newsletters from this site allow you to opt out of further communications.

Distribution of Information

We never use or share any of those information in ways unrelated to the ones described above. We do not send spam and we do not sell your information to any company for marketing purposes. We may, however, share information with government agencies or other companies assisting us in fraud prevention or investigation. We may do so when: (1) permitted or required by law; (2) trying to protect against or prevent actual or potential fraud or unauthorized transactions; or (3) investigating fraud which has already taken place.

Cookies and Tracking Technology

Our site may place a small file, called a cookie, on your hard drive to provide you with a better website. A cookie does not, in any way, give us access to your computer or to any personally identifiable information about you, other than the data you choose to share with us. It only helps us analyze web traffic or lets web applications respond to you as an individual. Our authorized third-party advertisers, in the course of serving ads to you, may also place and read cookies on your browser or use tracking technology to collect information. You can choose not to accept cookies by modifying your browser settings. At any time, you may remove any cookie stored on your hard drive by deleting them in your browser’s settings section.

Links to other Websites

Our site may contain links to other websites of interest. However, once you use these links to leave our site, we do not anymore have control over that website. Such sites are not governed by this privacy statement and we cannot be responsible for the protection and privacy of any information you provide to those sites. Exercise caution and read the privacy statement applicable to the website in question.

Privacy Contact Information

Should you have any questions, concerns, or comments about our privacy policy, please contact me directly at amdg2879@gmail.com.