Wednesday, November 21, 2018

Spotting a Scam - Not so easy!

Black Friday is Coming

In the run up to  Black Friday, the amount of online shopping advertising has obviously gone through the roof. With it inevitably comes a wide swathe of fraudulent advertising looking to trick unsuspecting shoppers into giving away their money or credit card details under false pretenses.

This year I was getting particularly heavily targeted by one particular scam. I had a quick look at the site in an attempt to give ordinary users some ideas on how to avoid scams and hopefully following some of the steps below should help. Ultimately, a scam may not be obvious and the only real defense is to be wary and look for sites with a real brand and a good reputation.

Brief look at a scam

The scam begins with a Facebook advert. I have obviously looked at something related to Lego as Facebook is absolutely hammering me with adverts like this one.



Now I personally would love to get my hands on the collector's edition of the Lego Millennium Falcon at a 70% discount so let's click through and see what there is.



Sure enough it's offering me the Millennium Falcon for $99, too good to be true as I happen to know that this model is pretty much unobtainable for anything under about $1000.

But how can we tell it is a scam? The site is marked as secure and is over HTTPS, surely that means that it is fine? Well no, all that means is that your details are encrypted when they are transferred to the site but it doesn’t mean that the site itself is secure or legitimate.

Now the site itself doesn’t seem to have any branding except for "Lego" although there is nothing here to indicate that it  is a legitimate Lego site.

Seem legit?

My next step was to search Google for information about the site, maybe someone would have indicated it was a scam.


This brings me a site which gives me some useful information about the suspicious site including how old it is and how well known it is.



Compare that to a better known site such as AliExpress which has a much better reputation and is more established.

So by this point, I think that we can be fairly comfortable that if I send money to that site, I will not be receiving my Millennium Falcon.

Let's go deeper...

I thought I would do a little more digging and went to find the site's numeric IP address and also other sites hosted on that same IP address.

This came back showing me at least three other site URLs using the same IP address, This isn't necessarily suspicious but I would not really expect it for a secure and trusted online shopping site. Especially seeing as the URLs do not obviously relate to the original site.

I also discovered that if I access the site via HTTP using its IP address rather than the URL, I got this somewhat unprofessional default landing page

Accessing the same IP address on a different TCP port showed a generic login page which again I wouldn't expect to see on a legitimate site.


I resisted the temptation to search for default username/password combinations for this system but I think it is safe to say that I don't have much confidence that my personal and credit card details would be secure if I sent them to this site!

Conclusion

Comsec have released advice for staying safe on Black Friday and I have included it below. The most important lesson is to be sceptical and look out for deals which are too good to be true!



Sunday, October 28, 2018

How to build security into Software Development?



Historically, companies have focused on implementing security controls around physical infrastructure, networks, servers and endpoints. This focus is potentially because many different technological solutions exist to help to protect these assets which can be managed in a centralized way using dashboards and remote consoles.

Examples of these kinds of solutions include next generation firewalls, anti-virus and advanced threat protection (ATP) tools, and Security Incident and Event Monitoring (SIEM) supported by threat intelligence processes.

However, the maturity level of security in the software development lifecycle (SDLC) remains some steps behind and I believe there are a few reasons for this.

Lack of time and the need to meet a deadline is always the first complaint when discussing implementing security controls beyond those which are default features in development frameworks, (for example).

The second complaint is around budget, especially if the development team is outsourced and are billing by the hour. Since security has not historically been considered a basic property of software code in the same way that performance and readability would be, it is still seen as an extra cost.

The third complaint is the lack of knowledge of many developers about basic security controls and the impact of the major security flaws already documented by security community. Hopefully all developers know about attacks such as SQL Injection, Cross-Site Scripting, Session Hijacking, etc. However, is quite clear that sometimes developers are missing the deep knowledge about the real consequences of successful exploitation of those flaws. For example, a developer may know that a SQL Injection attack may lead to data being stolen from a database but not be aware of other risks posed by the same attack such as getting a remote command shell on the server where the vulnerable database is hosted.

There are other examples of barriers to implementing a secure software development lifecycle, but with the increase in data breaches related to application vulnerabilities and the rise of known penalties such as those defined by GDPR, it is now easier to demonstrate the business case for companies to increase the maturity level of their secure development processes.

OWASP (the Open Web Application Security Project) is an international non-profit organization dedicated to application security. It provides very valuable resources ranging from tools to frameworks to documentation, all developed by a dedicated network of volunteers from around the world. Nowadays, it is the best repository where you can find all the information needed to raise the level of knowledge and skill of your technical and management teams.

The OWASP Top 10, for example, which is updated roughly every three years, is an excellent document to build awareness of the most common application vulnerabilities which have been noted in the last few years and the right controls and mitigations which can be used to avoid and fix them. However, it is clear that it is vital that security is included as early in the SLDC as possible since the later that security is introduced, the more expensive issues are to fix. The Top 10 project is probably not the most ideal project for including security early on in the SDLC nor is it comprehensive enough to help an organization reshape their SLDC to include security at each stage.

As such, I would like to discuss the OWASP Software Assurance Maturity Model (SAMM) project. This is an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization. This model defines four different Business Functions related to Software Development Lifecycle which the organization needs to address: Governance, Construction, Verification and Deployment.

These four Business Functions can be divided in 12 different Security Practices:

·       Governance (Business Function)

o   Strategy & Metrics (Security Practices)

o   Policy & Compliance (Security Practices)

o   Education & Guidance (Security Practices)

·       Construction (Business Function)

o   Threat Assessment (Security Practices)

o   Security Requirements (Security Practices)

o   Secure Architecture (Security Practices)

·       Verification (Business Function)

o   Design Review (Security Practices)

o   Code Review (Security Practices)

o   Security Testing (Security Practices)

·       Deployment (Business Function)

o   Vulnerability Management (Security Practices)

o   Environment Hardening (Security Practices)

o   Operational Enablement (Security Practices)

These twelve security practices can each help to increase the maturity level of the organization’s SDLC, in a measurable way. Implementing these practices can be planned step by step and the resulting changes and improvements can be monitored. Therefore, it represents a complete process that can be integrated into the SDLC and ensures that security is considered from the very first stages of the planning through to the application being deployed to production and on through the post-deployment phase as well, with ongoing vulnerability management as a continuous practice.

The activities related to each security practice are listed below:

·       Governance

o   Strategy & Metrics

§  Estimate overall business risk profile

§  Build and maintain assurance program roadmap

§  Classify data and applications based on business risk

§  Establish and measure per-classification security goals

§  Conduct periodic industry-wide cost comparisons

§  Collect metrics for historic security spend

o   Policy & Compliance

§  Identify and monitor external compliance drivers

§  Build and maintain compliance guidelines

§  Build policies and standards for security and compliance

§  Establish project audit practice

§  Create compliance gates for projects

§  Adopt solution for audit data collection

o   Education & Guidance

§  Conduct technical security awareness training

§  Build and maintain technical guidelines

§  Conduct role-specific application security training

§  Utilize security coaches to enhance project teams

§  Create formal application security support portal

§  Establish role-based examination/certification

·       Construction

o   Threat Assessment

§  Build and maintain application-specific threat models

§  Develop attacker profile from software architecture

§  Build and maintain abuse-care models per project

§  Adopt a weighting system for measurement of threats

§  Explicitly evaluate risk from third-party components

§  Elaborate threat models with compensating controls

o   Security Requirements

§  Derive security requirements from business functionality

§  Evaluate security and compliance guidance for requirements

§  Build an access controls matrix for resources and capabilities

§  Specify security requirements based on known risks

§  Build security requirements into supplier agreements

§  Expand audit program for security requirements

o   Secure Architecture

§  Maintain list of recommended software frameworks

§  Explicitly apply security principles to design

§  Identify and promote security services and infrastructure

§  Identify security design patterns from architecture

§  Establish formal reference architectures and platforms

§  Validate usage of frameworks, patterns and platforms

·       Verification

o   Design Review

§  Identify software attack surface

§  Analyze design against known security requirements

§  Inspect for complete provision of security mechanisms

§  Deploy design review services for project teams

§  Develop data-flow diagrams for sensitive resources

§  Establish releases gates for design review

o   Code Review

§  Create review checklists from known security requirements

§  Perform point-review of high-risk code

§  Utilize automated code analysis tools

§  Integrate code analysis into development process

§  Customize code analysis for application-specific concerns

§  Establish release gates for code review

o   Security Testing

§  Derive test cases from known security requirements

§  Conduct penetration testing on software releases

§  Utilize automated security testing tools

§  Integrate security testing into development process

§  Employ application-specific security testing automation

§  Establish release gates for security testing

·       Deployment

o   Vulnerability Management

§  Identify point of contact for security issues

§  Create informal security response team

§  Establish consistent incident response process

§  Adopt a security issue disclosure process

§  Conduct root cause analysis for incidents

§  Collect per-incident metrics

o   Environment Hardening

§  Maintain operational environment specification

§  Identify and install critical security upgrades and patches

§  Establish routine patch management process

§  Monitor baseline environment configuration status

§  Identify and deploy relevant operations protection tools

§  Expand audit program for environment configuration

o   Operational Enablement

§  Capture critical security information for deployment

§  Document procedures for typical application alerts

§  Create per-release change management procedures

§  Maintain formal operational security guides

§  Expand audit program for operational information

§  Perform code signing for application components



Whilst there are a lot of activities to implement here, it is important to execute at the correct pace. If activities are implemented too fast without monitoring metrics to check if each phase was successful and has been integrated into the organization’s processes, the implementation will ultimately fail and the security and other value benefits will not be realized.

It is particularly important to note that the activities in each security practice are ordered based on maturity meaning that an organization should initially focus on implementing the first activities across all the different practices and then once these initial activities are operating correctly, go back and start implementing the next activities, again across each the twelve practices.

The SAMM project documentation even provides metrics for each activity, staff needed and the estimated time that will be required per year for each member of the team to help the end-user ensure that they are implementing each activity in the correct way.

Note that SAMM isn’t the only methodology that can be used to improve the maturity level of a secure development process. Some examples of similar methodologies are BSIMM, ISMM (for IoT environments) or DASMM, this last one representing the implementation a combination of controls from both BSIMM and SAMM at the same time.

Independent of the methodology, is important to understand that everything must be grounded in the solid foundations of a good strategy, metrics to monitor performance and policies and procedures sponsored by management to ensure compliance with the new processes.

Ultimately, the key to success will be employee education to help everyone to understand the real need to improve the maturity level of secure development and to keep everyone updated and aware of their own role in the process.

Always remember to carefully monitor the entire process and establish SMART (Specific, Measureable, Achievable, Relevant, Timely) goals for each step. A good approach to adopt to help with the transformation is the Objectives and key results (OKR) methodology as this will make it easier to identify what needs to be achieved at each stage and what result is expected. The information for this is already provided by the SAMM methodology. There is a link to information on OKR in the references section.

Increasing the maturity of your Secure SDLC will be hard work, but the results should be worthwhile and be shown by an improvement in penetration testing results and decrease reduction in the risk of compromise via application vulnerabilities.



References:






DASMM - https://duo.com/blog/rsac-2018-building-a-software-security-maturity-program

Wednesday, October 24, 2018

What Application Security teams can learn from the Facebook breach

Background

On 28 September 2018, Facebook disclosed that they had discovered three vulnerabilities in their platform. They were subsequently able to determine that an attacker had exploited the combination of these vulnerabilities and this led to the disclosure of profile information of around 30 million of their users to the attacker.

Facebook have been relatively transparent about what they have found in two detailed blog-posts although the end result, the theft of access tokens, has wide ranging implications including affecting 3rd party web sites where a user uses their Facebook account to login. It was also suggested that the access tokens could be misused to affect 3rd party sites which a user had not used Facebook to login but which had configured in a certain way, allowing the attacker to create that link and login to the 3rd party site.

Facebook gave a detailed explanation of each of the three bugs in their blog-post but they boil down to the following:
  1. Missing authorisation on one out of a whole set of possible actions in a particular feature.
  2. Access token generated with incorrect permissions.
  3. Access token generated for incorrect user.
Whilst it is possible with the benefit of hindsight to see ways in which these issues could have been detected, there are a few important points to consider.

The challenge of business logic bugs

Bugs and vulnerabilities are always going to exist in code. Certain types of bugs such as Cross-site Scripting (XSS) or SQL Injection (SQLi) tend to follow a certain pattern which doesn’t rely on how the site works and are therefore easier to identify and prevent using standard secure development life-cycle controls such as static analysis or automated or manual dynamic testing (for example Burp scanner or a manual tester performing Application Security testing). Additionally, there may be ways of detecting these issues at run-time such as the report flag of the X-XSS-Protection header or alternatively a Web Application Firewall (WAF) which looks for suspicious content in requests.

However, vulnerabilities related to business logic (which applies to all three of the above issues) may not be immediately obvious and will be very hard to identify and prevent using any form of automated technique. They will also be hard to detect at run-time using any sort of pattern matching rule as they will generally not show an obvious pattern.

Another important point is that the number of bugs/vulnerabilities is going to be in proportion to the size and the complexity of the application. Facebook is clearly a very complex platform but it is certainly not the only organisation with this level of complexity.

Facebook has a highly skilled security team, a mature application security program and a well-developed bug bounty programme. They even went to the trouble of creating an entire test version of their application which ethical hackers can use to experiment and look for security vulnerabilities. Whilst they were unable to prevent this incident from occurring, the maturity of their application security programme meant that they were still able to detect and remediate the issue, despite the vulnerabilities being business logic bugs.

Detection at the application level

The OWASP (Open Web Application Security Project) Top 10 Most Critical Web Application Security Risks project provides a list of the most common and concerning web application security risks based on data and feedback provided by the application security community. The 2017 release included a number of new items, one of which was “Insufficient Logging and Monitoring”. The 2018 release of the OWASP Top 10 Proactive Controls project similarly includes “Implement Security Logging and Monitoring” as item number 9.

This brings us to the reason that Facebook were able to report this incident in the first place. Facebook have application level monitoring through which they noted the unusually high volume of token activity. This led to them carrying out an investigation which ultimately led to them detecting the attack. Interestingly, Facebook also have much more granular monitoring (which they have published information about here) which is designed to detect permission issues on an individual basis but this did not appear to catch the issue. Nevertheless, the fact that they had multiple layers of monitoring meant that they still detected the issue.

Advice on application level monitoring

We would strongly recommend that the key lesson which organisations should be taking from this incident is the importance of having a programme of implementing application level monitoring and continually improving and refining this process.

Organisations should start by instrumenting sensitive operations within the system such as when security validations fail or authentication and authorisation actions. The OWASP AppSensor project provides some ideas of the types of events and actions which should be monitored and recorded. A Web Application Firewall (WAF) may provide some of this functionality but it is unlikely to be able to capture business logic specific events.

The organisation should then start creating alerting rules around the events which have been captured based on how suspicious or dangerous they are. As a simple example, for something like an incorrect login, an alert may only be raised after a number of attempts. However, for something like an invalid value for a client-side validated field sent to a web API which would be a clear indicator of someone attempting to subvert the functionality, the alert may occur after only one incidence.

The organisation can then decide how these alerts will be received and consider proactive steps to take in response. This could range from just informing the operations team to throttling the connection with the suspicious activity. The application could even block particular users or sources or disable certain sensitive operations for them or for all users.

All of this activity should be implemented on an incremental basis whereby monitoring, alerts and actions are implemented on a gradual basis so as to assess the impact and benefit at each stage.

Conclusion

Many organisations have network or infrastructure level monitoring but this will only be able to detect a network or infrastructure level attack. This monitoring is still important but it will be completely unable to detect an application business logic attack of the sort experienced by Facebook. By investing in application level monitoring as well, even on an incremental basis, organisations will be in a far better position to detect these types of application level attacks.

This is a really interesting topic so if you want to discuss further, please feel free to get in touch using the details below. I hope to produce some more specific and detailed resources and guidance on this in the future.

Josh Grossman
Senior Information Security Consultant and Team Leader
joshg@comsecglobal.com

Thanks to Mikael Levy for reviewing and providing feedback on this post.


Wednesday, September 26, 2018

Comsec's Josh Grossman presenting at AppSec USA 2018

Come and meet Josh Grossman, one of our Application Division team leaders, at AppSec USA 2018 being held in San Jose, California in October!


What is AppSec USA?


AppSec USA is organised by OWASP, the Open Web Application Security Project as one of their two, annual, global conferences. It brings application security professionals from across the world together to hear about cutting edge topics and ideas in the industry through three, two day tracks of lectures. Talks are evaluated through a competitive Call for Papers process to ensure that the highest quality talks are presented at the conferences.

What will the talk be about?


Josh will be giving a talk entitled "How to get the best AppSec test of your life". In this talk, he uses his experience of delivering hundreds of application security testing projects to provide insights into how companies can get the maximum value from this process. The insights come from all stages of the testing process from scoping all the way to actioning the report and assessing next steps and can be applicable whether companies are doing these tests by choice or based on regulation, company policy or customer demands. 

The talk begins by explaining how you can "Hack your test" by choosing the assessment that makes the most sense for your organisation and then customizing the assessment for your needs. The talk covers discuss, what should you consider when choosing a provider? What should you request and expect from them up front? How should the scope should be defined to best use the time available and how should the time available be split across different stages of the assessment? How to balance realism and practicality?

The talk continues with ideas to ensure you are prepared for the test. If you are well prepared, the tester gets to spend the maximum of time working on your app rather than getting distracted with questions or logistics issues. The talk discusses recommended testing setups and which elements you should discuss with the tester up front. It also discusses classic errors and misconceptions that can lead to time wastage and inadequate results.

Finally, the most important part of the whole exercise: getting high quality, actionable output from the assessment. Many of the points discussed above will automatically lead to better assessment results by better tailoring the assessment but you still need an actionable report. This section starts with how to decide on the reporting process that is best for your organisation. It then discusses what you should expect from recommendations, what you should do when you receive them and how you can utilize your tester to decide on next steps.

What are the key takeaways?


Developers and others involved in a company's software development lifecycle will leave this talk with ideas that you can apply today, tomorrow and in the future to ensure that application security tests aren’t just a compliance tick-box but rather deliver real value and make an application more secure.

Monday, September 3, 2018

ISO 27001 Review- an inner view from comsec advisor

 Tiennot van Dilst- Principal Consultant / Delivery Manager – Comsec Benelux
During my career as a CSO and Security Consultant, I have worked with the ISO 27001 standard on various occasions. 
As a consultant I have helped various medium and large organizations in assessing and implementing the standard, whereas as a CSO I have been on the other side of the coin, being fully in charge of implementing the standard within the organization in which was working for.
I have also encountered the different pitfalls associated with implementing the standard and getting (part of) the organization certified.
I am writing this article in the hope that I can ease the mind of people in the Information Security field wanting to start to work with the standard, or who are looking to work with an external organization to support their implementation process.

So what is the ISO27001 Standard?

First of all, let me try to explain to you what the ISO 27001 standard (formally known as ISO/IEC 27001:2013) is all about. Many people are under the impression that when an organization is certified, it must be a secure organization…. I’m sorry to destroy that illusion for you but it is unfortunately not true. Being certified means that the organization has an information security management system (ISMS) implemented that, if maintained correctly, will enable the organization to manage their risks, implement and consolidate the selected and approved measurements and controls to mitigate those risks, and bring the risks down to an acceptable level.
The ISO 27001 standard does not provide a golden ticket showing you which controls you should implement. However, it does provide you with a management system which enables you to implement those controls. When implemented correctly, the management system will deliver continuous improvement of these implemented controls. The measures and controls themselves can differ from organization to organization, however the majority of organization conform to a standard control set, which is supplied as an annex to the standard, and which is fully described in the ISO 27002 guide, which focuses on the actual security controls.
Nevertheless, there are some controls in every ISMS that keep the management system operational which we cannot go without. For example, having a formal policy in place, a security organization, periodic reviews/audits and having an improvement process in place.
So two organizations can both be ISO 27001 certified, but have completely different control sets. In the Netherlands I have encountered this several times. Specifically, I have seen organizations where they are ISO 27001 certified but using the controls supplied by the Dutch health care standard NEN7510. 
In short: “ISO 27001 describes the requirements of the ISMS and you can certify parts of your organization or processes if they are working according to this management system, whereas ISO 27002 provides you with an implementation guide on how to implement the commonly used controls. (ISO 27002 is not a standard to which you can certify). 

It’s all about scope…
Especially (however not exclusively) in the IT department, when a company is looking for a service provider and requesting information, the suppling organization will try to baffle you with all the certifications they have. You will see that they say, almost by default “we are ISO27001 certified, so you should not worry about security”. In the meantime, they won’t tell you what is the exact scope of their certification. Lesson number one in this case should be to always ask them to explain to you exactly which part of the organization is certified, or even better ask them for their “statement of applicability”, which will show you the scope of the certificate and which controls have been implemented. 
On the other hand, when you looking to implement the standard in your own organization, make sure you find out exactly which part of your organization you want to be certified. In many cases, certifying your complete organization will overshoot the goal. Always keep in mind the additional value of having a certification and make sure that the important processes and assets (including their supporting processes) are in scope. 
While other processes might not be in scope for the certification, they can work according to your ISMS.

From unknowingly being at risk to willingly taking a risk….
So here we are, we are aware that the standard is about having a management system in place, and we know now what is important enough is to have in scope, what’s next? First of all, we need to consolidate the management system, meaning that we have to make sure that the right environment is set to create and maintain an ISMS. In many cases you will see in this phase that companies will create a security role or organization, describe the strategic policies (based upon the mission and vision of the company, local law and legislation and in some cases other factors like the position of the organization in the society, public interest, physical location etc.), and make sure we know what the important risks to the organization are. From these high level risks, we can filter operational risks, asset risks and process risks and think of (and document, and approve), measurements to bring the risk level down to an acceptable level.  
After implementation, the organization should check if the controls and measures are implemented correctly (Internal audits, technical reviews etc.), and management should be informed about the process on a regular basis. This cycle usually takes 3 months to a year and repeats itself annually.
Again, it’s not about fully mitigating the risks, it’s about knowing what your risks are and bringing them to an acceptable level.

Part of a normal schedule for activities within an ISMS could be: 

Activity 
  •  Risk analysis 
  • Review and update of policies
  • Review of the ISMS by management
  • Internal audits
  • External audits
Reoccurrence 
  • Annually 
  • Annually 
  • At least once a year 
  • Depends on what being audited:  Controls which consolidate the management system - annuallyControls which are part of the ISMS will depend on the importance of the measurement and the process or asset it is protecting. Can vary from once every 3 months to once every 3 years. Most controls should be reviewed at least once a year 
  • Every three years, a thorough ISMS review should be carried out, although every year the auditor will check if the ISMS is working correctly

You should always try to do better…
As I said before, every ISMS is created to guarantee a continuous improvement cycle. Points to improve are detected by doing the audits and reviews. Alongside that, it is important to have a process in place to detect and mitigate incidents. The main goals of the incident management process are to:  To detect and address breaches and or vulnerabilities in a timely manner;  To pinpoint the root cause of the incident; To learn from the incident.

Some tips based upon my experience: 
  • Certification is not the goal: In my career I have encountered organizations for which being certified was the goal. Even though I can see why, I would strongly suggest against it and especially not communicate it like that within the organization. My experience is that a lot of money, time and effort is spent in these cases and then, when the first certification audit is passed successfully, attention drops again, old habits reappear and, by the next cycle, most things need to be urgently redone right before the audit. Better to have the focus on the continuous improvement process so that the ISMS will start to work for you and not just guarantee a certification but rather also improve and streamline your organization and processes
  • Make use of the knowledge of your employees during internal audits: No need to have an internal auditor check every measure in every process or system. One of the tactics I used was to have the system administrator of system A periodically check the implementation of the controls on system B (not administered by him) and document the status. In that case, an internal auditor only has to check the reports and see if the controls have been checked correctly  
  • Stay away from disciplinary procedures: If an incident occurs by mistake, make sure that whoever caused the incident is not punished. Try to learn from it as an organization without placing someone on the wall of shame. 
  •  Start with the People: To implement an ISMS you will need the cooperation of everybody in the organization. Raising awareness throughout the organization is a great way to get everybody on board so start with that as soon as possible. 
  • Controls not in place: Do not panic, if it is not one of the controls designed to keep the ISMS working, you won’t fail an audit over it. Make sure it is well documented and in most cases I would advise to document it as a security incident and go through the incident management process to determine why it was not correctly implemented and what is the best course of action to correct it. Use the knowledge to learn from so that next time it won’t happen so easily. 
  • Make use of an external consultant: Usually implementing an ISMS is not the primary business of an organization and in most organizations, especially when starting the implementation, there is not much experience available. Hiring a professional consultant can immediately provide you with the experience you need, taking away a lot of the headaches you will encounter.  When hiring a consultant make sure they understand your business and speak the language of your company.

Of course the points described above only scratch the surface. In subsequent articles I will dive deeper into the material. However, if you have any questions, do not hesitate to contact myself or my Colleagues at Comsec.

Tiennot van Dilst CISSP CEH
Tiennotvd@comsecglobal.com

 

Thursday, August 23, 2018

Comsec sponsoring OWASP AppSec Israel 2018

AppSec Israel 2018

Comsec is proud to be a sponsor of OWASP’s AppSec Israel 2018 conference which is being hosted at Tel Aviv University at the start of September. This is the biggest Application Security conference in the region with speakers from both Israel and overseas presenting on cutting edge application security topics. This year’s conference will also include keynotes from internationally acclaimed experts, Jim Manico and Julie Baker.

About the conference

The conference starts on 5th September with a day of hands-on application security training aimed at helping developers, QA people and newcomers to the Application Security field to develop their skills in the field. That evening there will be special “Women In AppSec” session for women (and female-identifying) only.

The conference then continues on 6th of September with three parallel, full-day tracks of talks selected from a competitive submission process aimed at people at all levels of involvement in the software lifecycle. The conference talks have been at a consistently high level of quality year after year and this year looks like it will be no exception!

All events are free of charge and registration is already open at this link.

Meet us there

Comsec will have a booth in the sponsors area with both technical and HR staff on-hand and we would be delighted to see you there and talk to you about your Application and Cyber Security challenges as well as life working for Comsec and our current vacancies.

See below some photos from our booth last year: