Go on to the site to read the full article
Get the very latest news all in one place. Become a Facebook fan of RSA Conference. http://on.fb.me/p1hr8l
Go on to the site to read the full article
Crawling “classical” web applications is a problem that has been addressed more than a decode ago. Efficient crawling of web applications that use advanced technologies such as AJAX (called Rich Internet Applications, RIAs) is still an open problem. Crawling is important not only for indexing content, but also for building models of the applications, which is necessary for automated testing, automated security and accessibility assessments and in general for using software engineering tools. This paper presents a new strategy to crawl RIAs. It uses the concept of Model-Based Crawling (MBC) and introduces a new model, the “menu model”, which we show to be much simpler than previous models for MBC and more effective at building models than previously published methods. This method and others are compared against a set of experimental and real RIAs.
The SSRG research team will present these findings at ICWE 2013, 11 July@16:00, Aalborg, North Denmark.
Keywords: Crawling, RIAs, AJAX, Modeling
Suryakant Choudhary, Mustafa Emre Dincturk, Seyed Mirtaheri, Guy-Vincent Jourdan, Gregor Bochmann and Iosif Viorel Onut.
Building Rich Internet Applications Models: Example of a Better Strategy
in Proceedings of the 13th International Conference on Web Engineering (ICWE 2013), Aalborg, North Denmark, July 2013.
To be published in Lecture Notes in Computer Science by Springer.
Conference link: http://icwe2013.webengineering.org/
Accepted papers link: http://icwe2013.webengineering.org/accepted-full-papers
Link to the .pdf paper: http://ssrg.site.uottawa.ca/docs/ICWE2013.pdf
John Mueller and Mark Stewart ask the important questions about the NSA surveillance programs: why were they secret, what have they accomplished, and what do they cost?
By Henry Dalziel
In a previous blog post we looked at what it means to be a pentester (you might have heard the profession being termed an ‘ethical hacker’ or ‘penetration tester’). As we mentioned in that post, there are good and bad sides to the job. Good because you are following your interest and hopefully passion, and bad because there is a considerable amount of auditing and report-writing.
Being a penetration tester is a niche within the world of IT. Another niche is digital forensics; and that is what this post is all about.
A quick word why we are writing this post: we have a live chat feature throughout our site and we realized that the majority of enquiries that come through the live chat ask how they (the visitor to our site) can start their career within Information Security. The answer we give (the live chat is either handled by myself or Lily) is always the same: specialize! Seriously, that is our best advice. Rather than start off as a jack-of-all-trades, we suggest to get moving right away in a specialist field and digital forensics is a great niche. Not only is it in-demand but the pay is very good.
A computer can be a witness to a crime
Think about it. The drug dealer, terrorist, sexual predator or white-collared criminal can and in most cases do, use computers to manage their affairs, business and crimes. Sure, they think that are being smart by encrypting their data but that is where the digital forensics earns their pay. In much the same way that a physical witness can make or break a case, so it is the same with a machine that a criminal used and being able to make that evidence speak as if it was a real witness.
Patience is key
Just like our post about being a penetration tester, patience is key. As a matter of fact, even a bad-guy hacker needs patience! We all do! Digital forensics can take days even months to complete; the duration being something which is almost wholly dependent on the quality and quantity and level of encryption within the hard drives.
Windows, alas, is also a key OS you must learn inside and out
We use Linux more than we do Windows in the office (our designer uses Mac and Windows) but if you’d like to get into the forensics scene then Windows is your friend. We’d suggest switching your main OS to Windows if you have swung to Linux. We blog a lot about Linux penetration testing distros, with our favorite being BackBox, but let’s face it, most of the civilized world uses Windows, and the computers on which you will be researching will very likely be Windows. Windows 7 and to a degree I guess 8 are most widely used, and a working knowledge of Vista and XP will certainly be useful. What is critical is that you understand the inside of the Operating System intimately well, not least the registries and the entire file structures. You have to know what you are looking for and quickly. Your client (be they Police or a Fortune 500) will need deadlines to be met so you’ll need to work as fast as you can. Having to learn where and how to access files might be costly so learn the system now, today!
Now for a contradiction!
In the above we mentioned to use Windows as your daily OS – but you will – and must – become very familiar with a Linux forensics distro. We’d recommend CAINE, a distro we’ve blogged about a few times before. Central to the benefit of learning a specific Linux forensics distro is that all the necessary tools you’ll need to perform a concise and complete forensics audit will be contained with the distro, so learn it!
What does it take to be a forensics expert?
Passion, a capacity to learn, a desire to become an expert and a curious mind are necessary inherent skills that are required to become a successful digital forensics expert. Hardware, software, encryption methodologies are all evolving on a weekly basis – join an email list and you’ll see what we mean.
A digital forensics certification will certainly help as will work experience or if you are just starting out, evidence of your exposure to the subject by either having joined a local hacking club or having attended conferences etc. If you are invited to an interview you might be asked to perform a forensics test, such as how to recover deleted files. Learn how to do this so that you can do it in your sleep!
If you have got this far and you are still reading this then clearly you are interested – so go for it! There is demand for digital forensics, especially good ones, so get involved! Our final tip is to have a think about becoming a mobile device forensics expert. Smart phones are now commonplace, and there are not that many qualified professionals out there. Mobile device forensics would therefore be a very good choice if you are starting your career in security or thinking of migrating your career over to forensics.
Do you work in forensics? Let us know, we’d love to have and share your thoughts!
This is the last post in the security analytics with big data series. We’ll end with a discussion of deployment issues and concerns for any big data deployment, but also focus on issues specific to those leveraging SIEM. Please remember to post comments or ask questions you want to see addressed and I’ll answer in the comments.
Install any big data cluster or SIEM solution that leverages big data and you’ll notice that the documentation focuses on how to get up and running quickly and notes all the wonderful things you can do with the platform. The issues you really want to consider are left unsaid. You have to go digging for problems, but better find them now than after you’ve deployed. There are several items that are important, but let’s not beat around the bush: the single biggest challenge today is finding talent to help program and manage big data.
Talent, Or Lack Thereof
One of the principle benefits of big data clusters is the ability to apply different programatic interfaces, or select different query and data management paradigms. This is how we are able to do complex analytics. This is how we get better analysis from the cluster. Here is the problem: You can’t use it if you can’t code it. The people who manage you’re SIEM today are likely not developers. If you have a Security Operation Center (SOC), odds are many of them will have some scripting and programming experience, but likely not with big data. Today’s programatic interfaces means you have to have programmers, and possibly data architects who understand how to mine the data.
And there is another facet to it besides the programming. When we talk to architects of big data projects, like SOC personnel trying to identify attacks in event data, they don’t always know what they are looking for. They find valuable information hidden in the data, not magically just because they used a big data cluster, rather because they have talented personnel and statisticians writing queries and looking at the results. And after a few dozen iterations – or perhaps a few hundred iterations of query and review – they start to find interesting things.
People don’t use their SIEM this way. They want to quickly set a policy and have it enforced. They want alerts on malicious activity with the minimal amount of work.
For those of you not using SIEM, and building a security analytics cluster from scratch, you should not even start a project without an architect to aid in system design. Based upon the project goals, the architect will help you with platform selection and basic system design. Building the system will take some doing as well, as you will need someone to help manage the cluster, and you will need programmers to build the application logic and data queries. And you’re going to need someone who is versed in attacker behaviors to know what to look for and help these programmer stitch things together. There are only a finite number of qualified people out there today who can perform these roles. As we like to say in development circles, the quality of the code is directly linked to the quality of the developer. Bad developer, crappy code. And while many big data scientists, architects and programmers are well educated, most of them are new to both big data and security. That brilliant intern out of Berkeley is going to make mistakes, so expect some bumps along the way.
This is one of those areas where you need to consider leveraging the experience of your SIEM vendor and third parties in order to see your project through.
Policy development with big data is going to be harder in the short term. Why? Because, as we mentioned above, you can’t code your own policies unless you hire a programmer and possibly a data architect and statistician to help you out. SIEM vendors will eventually strap-on an abstraction interface to simplify big data query development, but we are not there yet.
Because of this, you will be more reliant on your SIEM vendor and third party service providers than before. And your SIEM vendor has yet to build-out all of the capabilities that you want from their big data infrastructure. They’ll get there, but it’s early in the big data lifecycle. In many cases the ‘advancements’ in SIEM will be to deliver previously advertised capabilities to now work as advertised. In other cases they will offer considerably greater depth of analysis because the queries will run against more data. Most vendors have been working in this problem space for a decade and understand the prior technical limitations, but now have some tools to address those issues. That means that they are addressing the thorniest issues first. And they can buttress existing near-real time queries with better behavioral profiles, provide slightly better risk analysis by looking at more – and more types – of data.
There is another facet of this difficulty as well that should be aired in public. Consider that when you have a radical shift in data management systems you should not assume a migration to a new big data platform will leverage the same queries. In fact, you may want to vet that any replacement queries yield the correct information. As we transition to new data management frameworks and query interfaces, the way we access and locate data changes. That’s important because, even if we stick to a SQL-like query language and run the same query we used to run, it does not mean that we will automatically get the same results. For better or worse, you’ll need to judge the quality of the derived information.
Data Sharing and Data Privacy
We’ve talked about the different models of integration previously. Some customers and potential customers we spoke with will want to leverage existing – non-security – information with their security analytics. Some are looking at creating partial copies of data stored in more traditional data mining systems, with the assumption that lower cost commodity storage make the iterative cost trivial. Others are looking to derive data from their existing clusters and import that information into Hadoop or their SIEM system. There is no ‘right’ way to approach this, and you’ll need to base you decision on what you are trying to accomplish, if leveraging existing infrastructure in fact provides added benefits big data cannot, and possible network bandwidth issues of moving information between these systems.
If you are considering moving sensitive data into your big data cluster, consider how you want to protect that data. This was not a question we heard from customers with traditional SIEM, both because the security model for relational databases was different, and because big data is now leveraging more types of data. But your choice will be to secure the cluster itself, which we will discuss next, or you may want to apply security to the data. Several firms we spoke with are using tokenization to substitute sensitive data prior to loading it into the cluster. The benefits of format and data type preservation are less critical in non-relational systems – on of the main benefits of tokenization in payment systems – but it does provide a means of referencing original data values if they are needed. Some firms are using masking to strip out sensitive data while retaining value for analytics. Still others are using format preserving encryption for specific columns.
Which of these options is not an easy question to answer as it depend upon how you want to use the data, and identifying a solution that will actually scale well enough to meet your needs. Still, if security of sensitive data is at issue, it is often easier to secure the data within the cluster than the cluster itself given the state of evolution for big data security.
Big Data Platform Security:
NoSQL platforms, for the most part, offer poor security. And those that are built into Hadoop are neither complete nor very well thought out. With the exception of a couple commercial big data vendors who bundle security tools into their solution, out of the box you will not have enough to secure a NoSQL cluster.
The types of security controls to consider are the following:
- Data Encryption: To protect data at rest, ensure administrators or other applications cannot gain direct access to files, and prevent leaked information from exposure. We recommend file/OS layer encryption as it scales as you add nodes, and is transparent to NoSQL operations.
- Authentication and Authorization: Ensure that there are administrative passwords in place, and that application users must authenticate before gaining access to the cluster. There should be segregation of roles for developers, users and administrators. These capabilities are built into some distributions, and can link to internal directory management systems.
- Node Authentication: There is little protection from adding unwanted nodes and applications to a big data cluster, especially in cloud and virtual environments where it is trivial to copy a machine image and start a new instance. Tools like Kerberos aid in node validation to ensure rogue nodes don’t issue queries or receive a copy of the data files.
- Key Management: Data encryption is only as good as key security; use an external key management system to secure keys and, if possible, help validate key usage.
- Logging: Logging is built into Hadoop and many other clusters. It may seem nonsensical to log system event data when using big data as a SIEM, but you should consider the security of the cluster a different problem than security of all other network devices and applications. We recommend that you enable built in logging, or leverage one of the many other open-source or commercial logging tools, to capture a subset of system events.
- Network Protocol Security: SSL or TLS is built in or available on most NoSQL distributions. If privacy is at all important, look to implement protocol security to keep your data private.
- Node Validation: Leverage tools to pre-configure, patch and validate nodes before they are addd to the cluster to ensure baseline security. Most of the customers we spoke with use it in virtual or cloud environments, which offer incredibly simple tools to achieve pre-deployment validation.
If you’re buying a SIEM based system, you’ll need to check to see how the vendor is securing their system. They will likely use a subset of these tools, but as they move from a monolithic single data repository model to a data cluster, these security controls become more important. Again, if you hear the work ‘proprietary’, you’ll need to dig into how the vendor addresses these security challenges.- Adrian Lane (0) Comments Subscribe to our daily email digest
:: Tim needs a new pair of shoes. :: goo.gl/KrBm9
Apple's (NASDAQ:AAPL) new MacBook Air is a hit with reviewers. Although some are disappointed that the 2013 model didn't get a Retina display, they're psyched with the battery life and improved performance. Mind you, they're still expensive and impossible to upgrade.
In #ITBW , bloggers count their pennies. #AAPL #Apple #macbookair #haswell
2013 Apple MacBook Air: Great battery, but pricey and limited