PYTHON VERSUS PERL: WHY THE DEBATE IS MEANINGLESS

   Vs  

Competition is a common thing is hackerdom, and arguments over which one of two (or more things) is the better are common and keep coming and going (but never really go away). Some of the most common ones are: Java vs C#, Emacs vs Vi (and it’s clones), Linux vs BSD, Closed Source vs Open Source and everyone’s favorite: Microsoft vs everyone else. And the internet is littered with evidence of these great wars (which none too rarely take on epic proportions) and some digging will throw up evidence on forums, website, bulletin boards, Usenet archives and of course, blogs. Today I’m taking a look at one of these wars that I’ve had personal experience with: Python vs Perl.

The last few years of my life have been filled with an as yet unfulfilled to learn some real programming (see last post). A few months ago I sat down to really learn Python, because I had a read a lot online about how it is a great beginner’s language (though I’m not really a complete newbie at this point). Anyway, I’ve been at it for a while and I’m liking how things are going.

But before I had started Python, I had a brief brush with Perl a year ago. At first glance it seemed something I had dreamed of. After struggling through memory management in C++ and Java and sitting through long compile times (which are really irritating if you’re a new programmer making lots of mistakes), Perl’s write and run was a dream and built in memory management made me a lot happier. But it didn’t take too long for me to get dissatisfied. Reading other people’s code was never very easy and variables behaving differently in different contexts was not something that I liked. I left Perl in just over a month.

Looking for an alternative I quickly found out about the Python vs Perl debate and was especially inspired by Eric Raymond’s Linux Journal article. I started Python and quickly fell in love with it. It had all the things I liked in Perl, but none of the eccentricities that I had wanted to leave behind. For a long term I didn’t give Perl another thought. But being the avid netizen, open source fan and linux lover, I kept reading about Perl here and there. So, last December, I decided to look into Perl again.

What I found out since then is that the Perl vs Python debate is rather like apples vs oranges. One of the biggest complaints about Perl is that it is untidy. Perl’s philosophy of “There’s More Than One Way To Do It” means that there are numerous ways to twist your code syntax around and it can be made absolutely unreadable. And it’s not just the syntax. Perl’s later features, especially object-orientation, have a distinctly kludge-like feel about them, as if they were simply slapped on later rather than integrated. Python, on the other is much cleaner and better designed. But there’s a twist to this tale. It’s this: Perl and are Python are very different languages.

Firstly Perl was not meant to be a general purpose language. It was meant to be a sort of shell-script on steroids. It’s a glue language, aptly called a Swiss Army Chainsaw. If you have a myriad of different programs and data sources and all you need to do is bind them with the electronic equivalent of duct tape, use Perl. Keeping Perl to it’s original uses makes most of the problems disappear. You don’t come into contact the kludginess of more advanced features because you will rarely (if ever) use them and readability isn’t so big a problem, because your programs will not genrally be more than a hundred or two lines.

Python on the other hand, is a more general purpose language. Features like object orientation are better implemented because you’re expected to use them all the time. And there is a definite emphasis on writing clean code because your programs will be big with complex tasks, not just delegating to other programs.

So the final word is this: choose your tools carefully. If you need something that will update a web page with a list of recently played songs, use Perl. A good example of how to use Perl effectively would be Xterminus’ changes page, which uses a Perl script to gather data from his del.icio.us account and his wiki software and create a pure HTML page. If you want to write anything with more than a few layers of abstraction and of more than medium complexity, grab Python. If you have any experience with these two, let me know.

Advertisements

Cross Site Scripting

Welcome to the hackers playground.

Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site. These scripts can even rewrite the content of the HTML page.

Most Web sites today add dynamic content to a Web page making the experience for the user more enjoyable. Dynamic content is content generated by some server process, which when delivered can behave and display differently to the user depending upon their settings and needs. Dynamic Web sites have a threat that static Web sites don’t, called “cross-site scripting,” also known as “XSS.”

“A Web page contains both text and HTML markup that is generated by the server and interpreted by the client browser. Web sites that generate only static pages are able to have full control over how the browser user interprets these pages. Web sites that generate dynamic pages do not have complete control over how their outputs are interpreted by the client. The heart of the issue is that if untrusted content can be introduced into a dynamic page, neither the Web sites nor the client has enough information to recognize that this has happened and take protective actions,” according to CERT Coordination Center, a federally funded research and development center to study Internet security vulnerabilities and provide incident response.

Cross-site scripting is gaining popularity among attackers as an easy exposure to find in Web sites. Every month cross-site scripting attacks are found in commercial sites and advisories are published explaining the threat. Left unattended, your Web site’s ability to operate securely, as well as your company’s reputation, may become victim of the attacks.

This article is written to raise the awareness of this emerging threat and to present a solution implementation for Web applications to avoid this kind of attack.

The threats of cross-site scripting

Cross-site scripting poses server application risks that include, but are not limited to, the following:

  • Users can unknowingly execute malicious scripts when viewing dynamically generated pages based on content provided by an attacker.
  • An attacker can take over the user session before the user’s session cookie expires.
  • An attacker can connect users to a malicious server of the attacker’s choice.
  • An attacker who can convince a user to access a URL supplied by the attacker could cause script or HTML of the attacker’s choice to be executed in the user’s browser. Using this technique, an attacker can take actions with the privileges of the user who accessed the URL, such as issuing queries on the underlying SQL databases and viewing the results and to exploit the known faulty implementations on the target system.

 

Launching an attack

After an application on a Web site is known to be vulnerable to cross-site scripting, an attacker can formulate an attack. The technique most often used by attackers is to inject JavaScript, VBScript, ActiveX, HTML, or Flash for execution on a victim’s system with the victim’s privileges. Once an attack is activated, everything from account hijacking, changing of user settings, cookie theft and poisoning, or false advertising is possible.

 

Sample attack scenarios

The following scenario diagrams illustrate some of the more relevant attacks. We will not, however, be able to list all variants of the vulnerability. To learn more about the documented attacks and how to protect yourself as a vendor or as a user, see the Resources section.

Scripting via a malicious link

In this scenario, the attacker sends a specially crafted e-mail message to a victim containing malicious link scripting such as one shown below:

<A HREF=http://legitimateSite.com/registration.cgi?clientprofile=<SCRIPT>malicious code</SCRIPT>>Click here</A>

When an unsuspecting user clicks on this link, the URL is sent to legitimateSite.com including the malicious code. If the legitimate server sends a page back to the user including the value of clientprofile, the malicious code will be executed on the client Web browser

 

Stealing users’ cookies

If any part of the Web site uses cookies, then it may be possible to steal them from its users. In this scenario, the attacker files a page with malicious script to the part of the site that is vulnerable. When the page is displayed, the malicious script runs, collects the users’ cookies, and sends a request to the attacker’s Web site with the cookies gathered. Using this technique, the attacker can gain sensitive data such as passwords, credit card numbers, and any arbitrary information the user inputs

Sending an unauthorized request

In this scenario, the user unknowingly executes scripts written by an attacker when they follow a malicious link in a mail message. Because the malicious scripts are executed in a context that appears to have originated from the legitimate server, the attacker has full access to the document retrieved and may send data contained in the page back to their site.
If the embedded script code has additional interactions capability with the legitimate server without alerting the victim, the attacker could develop and exploit that posted data to a different page on the legitimate Web server

Avoiding an attack

As stated above, cross-site scripting is achieved when an attacker is able to cause a legitimate Web server to send a page to a victim user’s Web browser that contains a malicious script of the attacker’s choosing. The attacker then has the malicious script run with the privileges of a legitimate script originating from the legitimate Web server.

Now that we know the basis of an attack, what can we do to protect ourselves from this vulnerability?

Web site developers can protect their sites from being abused in conjunction with these attacks by ensuring that dynamically generated pages do not contained undesired tags.

From the Web user’s perspective, two options exist to reduce the risk of being attacked through this vulnerability. The first — disabling scripting languages in the Web browser as well as the HTML-enabled e-mail client — provides the most protection but has the side effect of disabling functionality. The second — only following links from the main Web site for viewing — will significantly reduce a user’s exposure while still maintaining functionality.

However, none of the solutions that Web users can take are complete solutions. In the end, it is up to Web page developers to modify their pages to eliminate these types of problems. This can be accomplished by properly filtering and validating the input received and properly encoding or filtering the output returned to the user.

Filtering

The basis of this approach is never trust user input and always filter metacharacters (“special” characters) that are defined in the HTML specification. Each input field, including link parameters will be validated for script tags. When found and dependent on the context, the input will be rejected and thus prevent the malicious HTML from being presented to the user.

Adding to the complexity is that many Web browsers try to correct common errors in HTML. As a result, they sometimes treat characters as special when, according to the specification, they are not. Therefore, it is important to note that individual situations may warrant including additional characters in the list of special characters. Web developers must examine their applications and determine which characters can affect their web applications.

Filtering on the input side is less effective because dynamic content can be entered into a Web site database via methods other than HTTP. In this case, the Web server may never see the data as part of the data input process and the data elements still remain tainted. Alternatively, it is recommended that filtering be done as part of the data output process, just before it is rendered as part of the dynamic page. Done correctly, this approach ensures that all dynamic content is filtered.

Encoding

Cross-site scripting attacks can be avoided when a Web server adequately ensures that generated pages are properly encoded to prevent unintended execution of scripts.

Each character in the ISO-8859-1 specification can be encoded using its numeric entry value. Server side encoding is a process where all dynamic content will go through an encoding function where scripting tags will be replaced with codes in the chosen character set.

Generally speaking, encoding is recommended because it does not require you to make a decision about what characters could legitimately be entered and need to be passed through. Unfortunately, encoding all untrusted data can be resource intensive and may have a performance impact on some Web servers.

 

Which strategy is right for me?

CGI-based Web applications or applications that favor field edit check at the browser will likely adapt to the filtering strategy by extending the existing field edit check to cover the cross-site scripting vulnerability. Note that although browser side field edit check saves a few runs back to the server, it only works for the honest user and requires thorough code walkthroughs to guarantee that all input fields are checked in order to meet the remediation recommendation. Web applications with server side validation designed-in, however, can have a choice to adapt to either or both strategies.

For the filtering strategy to work properly, Web developers need to ensure that the list of metacharacters for filtering is up-to-date according to the needs of their applications. The encoding strategy, on the other hand, does not have the above-described maintenance effort, and it also has less impact on the existing application code as well as on application functionality. For these reasons, the encoding strategy appears to be a favorite choice of implementation. A sample encoding implementation is described next.

 

The 1-2-3 of a sample encoding

A simple, yet effective, way for a Web server to ensure that the generated pages are properly encoded is to pass each character in the dynamic content through an encoding function where the scripting tags in the dynamic content are replaced with codes in the chosen character set. This task is perfect for a custom tag library.

Custom tag library basics

A custom tag library is comprised of one or more Java language classes (called tag handlers) and an XML tag library description file (TLD), which dictates the new tag names and valid attributes for those tags. Tag handlers and TLDs determine how the tags, their attributes, and their bodies will be interpreted and processed at request time from inside a JSP page. A custom tag library provides an architecture that is more flexible than a Java bean at encapsulating a complex operation.

 

Our “custom” fitted tag library

What better name is there for our custom tag library besides naming it XSS? Tag libraries are software components that are plugged into a servlet container. The servlet container creates tag handlers, initializes them and calls the doStartTag(), doEndTag() and release() methods, in that order.

Through these interactions, our XSS custom tag library will be able to apply the “custom” action of encoding the dynamic data found on a JSP page. Implementing custom tags is straightforward and the steps are as follows:

  • Create a tag library descriptor (.tld) describing the tags.
  • Add a taglib directive to JSP files that use the tags.
  • Implement a tag handler that extends TagSupport and overrides the doStartTag() or the doEndTag() methods.

TLD (tag library descriptor)

A tag library descriptor is an XML file whose elements describe a particular tag library. The tld file for our XSS custom tag library, is shown in Listing 1. The tag element defines the encode action, including an attribute, property. The tagclass element defines the tag handler class EncodeTag.
Listing 1. The xss.tld file

				
<?xml version="1.0" encoding="UTF-8"?>
 DOCTYPE taglib 
   PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.1//EN" 
   "http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd">

<taglib>
     <tlibversion>1.0</tlibversion>
     <jspversion>1.1</jspversion> 
     <tag>
        <name>encode</name>
        <tagclass>dw.demo.xss.EncodeTag</tagclass>
        <bodycontent>empty</bodycontent>
        <attribute>
            <name>property</name>
            <required>true</required> 
        </attribute>
     </tag>
<taglib>

 

The taglib directive

The taglib directive identifies the tag library descriptor and defines the tag prefix that associates subsequent tags with the library. A sample taglib directive, which appears in the JSP using the XSS custom tag library, is shown below:

 

			
   <%@ taglib uri="/WEB-INF/tlds/xss.tld" prefix="xss" %>

 

Coding the tag handler

A tag handler is an object in the Web container that helps evaluate actions when a JSP page executes. The EncodeTag class is the tag handler for the encode action. Its doStartTag method, which encodes the dynamic content to the ISO-8859-1 character set, is shown in Listing 2.
Listing 2. Encoding the dynamic content

				
 public int doStartTag() throws JspException {

     StringBuffer sbuf = new StringBuffer();

     char[] chars = property.toCharArray();
     for (int i = 0; i < chars.length; i++) { 
          sbuf.append("&#" + (int) chars[i]);
     }     

     try{
          pageContext.getOut().print(sbuf.toString());     
     } catch (IOException ex) {
          throw new JspException(ex.getMessage());     
     }     

     return SKIP_BODY;
 }

 

 

Deployment

The XSS custom tag library, which is part of a Web application, is packaged as additional files into the Web application’s WAR file as follows:

  • WEB-INF/lib/encodetaglib.jar
  • WEB-INF/tlds/xss.tld

 

Putting it to work

The following scenario illustrates how the custom tag library would be used. Suppose that a hypothetical Web site for receiving articles included a page for reviewing articles that you have subscribed-to. The dynamic content, article items intended for you, is prepared inside a JSP file using the <%= expression %> syntax.

What is Ethical Hacking

By P. Walsh
An Ethical Hacker is an expert hired by a company to attempt to attack their network and computer system the same way a hacker would. Ethical Hackers use the same techniques and tactics as those used by illegal hackers to breach corporate security systems. The end result is the company’s ability to prevent an intrusion before it ever occurs.

A company can’t know if their security system is solid unless they test it. It’s hard, though, for a company’s IT team to thoroughly ring out the system. Try as they might, the techs can’t go at the system with all the malicious or mischievous motives of a true illegal hacker. To thoroughly uncover vulnerabilities, the theory goes; you must examine your security system through the eyes of an illegal hacker.

The word hacking has strongly negative connotations, and, for the most part, rightly so. But ethical hacking is much different. It takes place with the explicit permission of the company whose system is being attacked. In fact, their “good guy” role is underscored by the nickname “white hat” Ethical Hackers have been given. The nickname is a throwback to old Westerns where the good cowboys could be identified by their white hats.

The company and the Ethical Hacker enter into a legally binding contract. The contract, sometimes called a “get out of jail free card,” sets forth the parameters of the testing. It’s called the “get out of jail free card” because it’s what harbors the Ethical Hacker from prosecution. Hacking is a felony, and a serious one at that. The terms of the agreement are what transform illegal behavior into a legal and legitimate occupation.

Once the hacker has exhausted his attempts, he reports back to the company with a list of the vulnerabilities he uncovered. The list in and of itself, however, is not particularly useful. What’s most valuable is the instructions for eliminating the vulnerabilities that the Ethical Hacker provides.

An Ethical Hacker works to uncover three key pieces of information. First, he determines what information an illegal hacker can gain access to. Next, he explores what an illegal hacker could do with that information once gained. Last, the Ethical Hacker ascertains whether an employee or staff member would be alerted to the break-in, successful or not.

At first it might sound strange that a company would pay someone to try to break into their system. Ethical hacking, though, makes a lot of sense, and it is a concept companies have been employing for years. To test the effectiveness and quality of product, we subject it to the worst case scenario. The safety testing performed by car manufacturers is a good example. Current regulatory requirements including HIPAA, Sarbanes Oxley, and SB-1386 and BS 799 require a trusted third party to check that systems are secure.

In order to get the most out of the assessment, a company should decide in advance the nature of the vulnerabilities they’re most concerned with. Specifically, the company should determine which information they want to keep protected and what they’re concerned would happen if the information was retrieved by an illegal hacker.

Companies should thoroughly assess the qualifications and background of any Ethical Hacker they are considering hiring. This individual will be privy to highly sensitive information. Total honesty and integrity is of the utmost importance.

How to Become an Ethical Hacker

Not all hackers do evil work. Here’s what you need to know to use your hacking skills to do good.

Do viruses, DDoS attacks, or buffer overflows tickle your fancy? If so, you might consider becoming a legal hacker, aka an ethical hacker, “white hat” hacker, or penetration tester.

Businesses and government-related organizations that are serious about their network security hire ethical hackers and penetration testers to help probe and improve their networks, applications, and other computer systems with the ultimate goal of preventing data theft and fraud. You may not get the same adrenaline rush that you might with underground hacking, but you can earn a good and honest living–and not end up facing prison time, as some illegal “black hat” hackers do.

How does the job market look like for ethical hackers? Extremely good! The IT market overall continues to grow despite the current economic turmoil. Research firm Gartner estimates that worldwide enterprise IT spending grew by 5.9 percent between 2009 and 2010, to a total of $2.7 trillion. At the same time, security is becoming a more pressing concern. Gartner expects to see an increase of nearly 40 percent in spending on worldwide security services during the five-year period from 2011 to 2015, eventually surpassing $49.1 billion.

In your first years as an ethical hacker, you’ll be in a position to earn anywhere from $50,000 to $100,000 per year, depending on the company that hires you, and on your IT experience and education. With several years of professional experience, you could command $120,000 or more per year, especially if you do your own independent consulting.

You can’t just dive into an ethical hacker position, however. Without IT security experience, you won’t get very far, even with degrees and certifications. As is true for other IT jobs, employers typically want candidates who have college degrees, but related experience is king. And experience with certifications can typically take the place of some degree requirements.

Getting Started

What you need to do to get started on the road to becoming an ethical hacker depends on where you are in the IT field. If you haven’t started your IT career yet, you might even consider military service. The military offers many IT opportunities, and you get paid to go to school, even if you enlist in a part-time branch such as the National Guard or Reserves. Military service also looks good to employers that require security clearances.

Start with the basics: Earn your A+ Certification and get a tech support position. After some experience and additional certification (Network+ or CCNA), move up to a network support or admin role, and then to network engineer after a few years. Next, put some time into earning security certifications (Security+, CISSP, or TICSA) and find an information security position. While you’re there, try to concentrate on penetration testing–and get some experience with the tools of the trade. Then work toward the Certified Ethical Hacker (CEH) certification offered by the International Council of Electronic Commerce Consultants (EC-Council for short). At that point, you can start marketing yourself as an ethical hacker.

For a hacker, networking know-how is vital; but make sure that you gain experience in related areas as well. Discover and play with Unix/Linux commands and distributions. Make sure you also learn some programming–maybe C, LISP, Perl, or Java. And spend some time with databases such as SQL.

Soft Skills

Hacking isn’t all technical. It also requires so-called soft skills, just as any other IT job does. You’ll need a strong work ethic, very good problem-solving and communications skills, and the ability to say motivated and dedicated.

Ethical hackers also need street smarts, people skills, and even some talent for manipulation, since at times they need to be able to persuade others to disclose credentials, restart or shut down systems, execute files, or otherwise knowingly or unknowingly help them achieve their ultimate goal. You’ll need to master this aspect of the job, which people in the business sometimes call “social engineering,” to become a well-rounded ethical hacker.

Stay Legal!

It’s important never to engage in “black hat” hacking–that is, intruding or attacking anyone’s network without their full permission. Engaging in illegal activities, even if it doesn’t lead to a conviction, will likely kill your ethical hacking career. Many of the available jobs are with government-related organizations and require security clearances and polygraph testing. Even regular companies will perform at least a basic background check.

Becoming a Certified Ethical Hacker (CEH)

As noted earlier, becoming a Certified Ethical Hacker (CEH) involves earning the appropriate credential from the EC-Council after a few years of security-related IT experience. The certification will help you understand security from the mindset of a hacker. You’ll learn the common types of exploits, vulnerabilities, and countermeasures.

Qualification for a CEH (a vendor-neutral certification) involves mastering penetration testing, footprinting and reconnaissance, and social engineering. The course of study covers creating Trojan horses, backdoors, viruses, and worms. It also covers denial of service (DoS) attacks, SQL injection, buffer overflow, session hijacking, and system hacking. You’ll discover how to hijack Web servers and Web applications. You’ll also find out how to scan and sniff networks, crack wireless encryption, and evade IDSs, firewalls, and honeypots.

Through approved EC-Council training partners, you can take a live, five-day onsite or online training course to prepare for the CEH cert. You can generally take live online classes over five consecutive days; onsite courses typically offer the content spread over a couple weeks for locals. In addition, you can take self-paced courses and work with self-study materials (including the CEH Certified Ethical Hacker Study Guide book) with or without the training courses. The EC-Council also offers iLabs, a subscription based-service that allows you to log on to virtualized remote machines to perform exercises.

The EC-Council usually requires that you have at least two years of information-security-related work experience (endorsed by your employer) in addition to passing the exam before it will award you the official CEH certification.

Resources

If you’re interested in ethical hacking, you can consult many useful resources for more information. To start, check the resources section of the EC-Council site. A quick Amazon search will reveal many books on ethical hacking and the CEH certification, as well.

With some googling, you can find simple hacking how-tos, which may motivate you even more. Consider downloading the Firefox add-on Firesheep or the Android app Droidsheep, and hijack your online accounts via Wi-Fi (but don’t use these tools to hijack others’ accounts–you could find yourself in legal trouble if you do).

Another option is to experiment with the BackTrack live CD. Try enabling WEP security on your wireless router at home, and then take a stab at cracking it. Check out Hack This Site to test and expand your skills. You could even set up a Linux box with Apache or buy a used Cisco router and see what you can do with it. If you want to play with malware, consider downloading–cautiously, and at your own risk–a malware DIY kit or a keylogger, and use it to experiment on a separate old PC or virtual machine.

Like other IT areas, hacking has conventions and conferences dedicated to it, such as DefCon, one of the oldest and largest of these. Such gatherings can be a great place to meet and network with peers and employers, and to discover more about hacking. DefCon also has affiliated local groups in select areas.

And remember, never attack or intrude on anyone else’s network or computers without full written permission.

Eric Geier is the founder of NoWiresSecurity, which helps businesses easily protect their Wi-Fi networks with the Enterprise mode of WPA/WPA2 security by offering a hosted RADIUS/802.1X service. He is also a freelance tech writer—become a Twitter follower or use the RSS Feed to keep up with his writings

Pro’s and Con’s of Ethical Hacking

The use of ethical hackers to test for security vulnerabilities is as old as the IT hills. But, unless there are clear goals outlining why and to what extent your organization is engaging them, the outcome could be useless information — or worse.

On the surface, ethical hacking sounds like a pretty straightforward process: You hire somebody to break into your network or application or Web servers, and report what they find. But this simple description, which does adequately explain the basic principal, masks a process that requires a great deal more thought.

Unless you first know what it is you are looking for and why you are hiring an outside vendor to hack your systems in the first place, chances are you won’t get much out of the experience, said Arian Evan, a senior security engineer at FishNet Security. Sure, you will find out your network needs to be patched or there are X number of security holes, but if that information is not relatable back to the business in some form, it’s pretty much useless.

“If you just want numbers, any of us can run a scan and give you results,” agreed Paul Klahn, FishNet’s director of assessment services.

Beyond the Numbers

To get the most from a test, putting results into a business context is imperative, said Klahn. Which holes are truly a security threat? How deep into the network can a hacker get via one of these holes? Which should be patched first?

Security holes can even be a necessary part of your infrastructure, allowing you to do business with partners, for example, so closing them up for security reasons may cause more headaches than the vulnerability. Your contractor should be able to appreciate this nuance.

Invariably, threats will be found, said Albert Decker, executive director of EDS’s Security and Privacy services, and a former ethical hacker with 25 years in the business and a 99% success rate at getting around corporate security.

“It became roughly the equivalent of ‘Can you throw this brick through a window?’ and the answer is, invariably, unless you miss the window, it will break the glass,” Decker said, commenting on his days as a hacker.

Because not much has changed since Decker was actually scanning code, the firm you hire should be able to provide you with a threat assessment and articulate remedies that take into account business needs. And, even then, the hack should be part of a larger security audit that looks at known vulnerabilities while comparing your IT governance policies and procedures against industry best practices.

Snapshot

The reason for this, said Jim Goddard, an ethical hacker at IBM, is simple: If you just hire a hack and do nothing else, on the day it’s complete, you are no more secure than the day before the hack began. This is because hacking provides just a snapshot of your overall security. Yes, it can provide confirmation your security is good or expose unknown threats, but it can’t tell you what those threats will be tomorrow. One configuration change and much of the hacker’s work can be negated, agreed Decker.

“The use of hackers is essentially a point-in-time test for a continuous problem,” said Decker. “It’s only giving you one very narrow slice of your environment which could change, literally, the second after the test is completed.”

There are four basic kinds of hacks you can have done, said Goddard:

 

  • IP Hack: You hire someone to hack a specific IP address, giving them little or no information beforehand (Be careful if the IP address is an overseas server. You don’t want hackers hacking the wrong IP address, like a foreign government’s computers, causing an international incident.);

 

  • Application Hack: A much more sophisticated hack that can delve deep into databases and down production servers. Only experienced hackers, with strict guidelines governing their actions, should be allowed to perform such tests. Never hire a “reformed” black-hat hacker for this type of test;

 

  • Physical Infrastructure Hack: This is where people try to get into your facilities to access your systems or go dumpster diving looking for confidential information such as passwords discarded on sticky notes; and

 

  • Wireless Hack: War-driving is the new term to describe this type of attack where wireless access points are exploited from the back of a van. Ethical hackers do the same thing, but report their findings back to you instead of stealing your passwords. Have them check out your teleworkers as well to see if home offices are a source of entry to your network.

For any of these tests, a reputable firm with clearly defined methodologies should be hired, cautioned Goddard. If a company can’t tell you exactly how it conducts its business, move on. And never hire former hackers to do the work on the cheap. They may not be as reformed as they say and could leave back doors behind or worse, he said.

Scope & Limits

Once a vendor is selected (never use the RFP process for this type of work, cautions Evans, interview prospective companies), it is very important to outline and define the scope of the project — you don’t want the hacker deciding where to start and stop an attack. Delegate a point person with decision-making authority the hackers can contact day or night if problems arises and authority to continue is required.

But, perhaps most importantly, know what you are looking to get from the experience. Too often, said Decker, companies conduct these tests and feel they are secure. This is not the case. Ethical hacking is just another tool, not a panacea. If viewed as such, it will fall into its proper place alongside other security tools. If not, it can leave you far more exposed through either false feelings of security or outright damage to your systems.

“There’s many, many different things we can do on a network that fall in or around ‘ethical’ hacking,” said FishNet’s Evans, ” … but, without that business case, its very hard to help the client make decisions about what technology services and perspectives they need.”

What's On My PC

If you are into networking, you most likely have heard of Radmin Remote Access Software. To promote Radmin, I noticed that they offer a FREE IP Scanner called Advanced IP Scanner that is helpful in locating and monitoring the devices (wired or wireless) that are connected to your network (home or business).  Scanners such as this is helpful in identifying the IP addresses (which dynamically can change) and MAC Addresses of those devices.  Years ago when I managed a network, I used an IP scanner such as this to make sure all of my network devices and computers were alive and functioning properly.

Advanced IP Scanner is a free, fast and easy-to-use network scanner for Windows. In a matter of seconds, Advanced IP Scanner can locate all the computers on your wired or wireless local network and conduct a scan of their ports. The program provides easy access to…

View original post 188 more words

Computing Education Blog

In the About page for this blog, I wrote, “Computing Education Research is about how people come to understanding computing, and how we can facilitate that understanding.”  Juha Sorva’s dissertation (now available!) helped me come to an understanding of what it means to “understand computing.”  I describe a fairly technical (in terms of cognitive and learning sciences) definition, which basically is Juha’s.  I end with some concrete pedagogical recommendations that are implied by this definition.

A Notional Machine:  Benedict DuBoulay wrote in the 1980’s about a “notional machine,” that is, an abstraction of the computer that one can use for thinking about what a computer can and will do.  Juha writes:

Du Boulay was probably the first to use the term notional machine for “the general properties of the machine that one is learning to control” as one learns programming. A notional machine is an…

View original post 1,549 more words