Tag Archives: Atlassian JIRA

Managing JIRA Scrum Sprints using API

Atlassian Jira is a great tool for organizing Agile processes, especially Scrum. But managing Scrum Sprints manually using Jira web GUI maybe time consuming and annoying. So, I decided to automate some routine operations using JIRA API and Python.

The API calls are described on the official page at JIRA Agile REST API Reference.

Managing JIRA Agile Sprints using API

I will use my domain account for authentication. First of all let’s see how to get Jira Scrum Board ID by it’s name and get all the Sprints related to the Board.

Continue reading

Atlassian Jira, Python and automated labeling

I have already wrote about Atlassian Jira automation in “Automated task processing with JIRA API“. But all examples there were with using of curl. So, I decided to make one more post about Jira API. This time with python examples and about labeling issues (nice wordplay, right? 😉 ).

Jira Labels and Python

You can use labeles for organizing issues on Jira Scrum and Kanban Boards, Jira Dashboards or just for advanced searching (e.g. labels = "LabelName")

Let’s start from the basics.

How to search Jira issues from your own python scripts?

It’s easy. Send a post request to /rest/api/2/search/ with some JQL expression. Jira server will return first 50 matching issues. If you need more, set a startAt parameter and repeat post requests while the number of issues you requested is less than total number of founded issues (parameter in response).

Continue reading

Vulnerability Management for Network Perimeter

Network Perimeter is like a door to your organization. It is accessible to everyone and vulnerability exploitation does not require any human interactions, unlike, for example, phishing attacks. Potential attacker can automate most of his actions searching for an easy target. It’s important not to be such of target. 😉

Vulnerability Management for Network Perimeter

What does it mean to control the network perimeter? Well, practically this process consist of two main parts:

  • Assessing network hosts that are facing Internet using some Network Scanner (Nessus, OpenVAS, Qualys, MaxPatrol. F-Secure Radar, etc.)
  • Assessing application servers, e.g. Web Servers, on these hosts using some special tools, e.g. Web Application Scanners (Acunetix, Burp Suite, Qualys WAS, Tenable.io WAS, High-Tech Bridge ImmuniWeb, etc.)

Active scanning is a good method of perimeter assessment. Dynamics of the assets is relatively low, comparing with the Office Network. Perimeter hosts usually stays active all the time, including the time when you are going to scan scanning them. 😉

Most of the dangerous vulnerabilities can be detected without authorization: problems with encryption (OpenSSL Heartbleed, Poodle, etc.). RCE and DoS of web servers and frameworks (Apache Struts and Equifax case)

The best results can be achieved with scanners deployed outside of your network. Thus, you will see your Network Perimeter the same way a potential attacker sees it. But certainly, you will be in a better position:

  • You can ask your IT administrators to add your network and WAS scanners in white list, so they will not be banned.
  • You can check and correlate scan results of remote scanner with (authenticated?) scan results produced by the scanner deployed in your organization’s network and thus filtering false positives.

What about the targets for scanning? How should you get them?

Continue reading

Tracking software versions using Nessus and Splunk

Let’s say you have already exported scan results from Nessus or Tenable SecurityCenter to Splunk using HTTP event connector, or in some other way. And you see that some critical software vulnerability was published. For example, this month Jira critical vulnerability. How to find out, do we have vulnerable servers in our infrastructure or not?

Nessus plus Splunk

Of course we can start a new Nessus scan to detect vulnerable hosts. However, Nessus plugin for this particular vulnerability may be released with a big latency and you will not find this vulnerability in your scans. So, it’s may be faster just to search for detected Jira servers in available scan results using Splunk searching mechanism.

Continue reading

Automated task processing with JIRA API

It’s no secret that task tracker is one of the most critical resources of any big organization. The whole working process can be represented as creating, processing and closing various tasks. Without task tracker there will be complete disaster, collapse and anarchy. So, it’s very important to work with this instrument efficiently. And when I write efficiently, I mean in automated way. It’s a blog about security automation after all. 😉

This post will be about Jira task tracker. I have already wrote how Jira can be used in VM Remediation process. That post was mainly about the main principles and how remediation tasks look in Jira WEB-GUI. Now, I will go further and show how to use it as a source of important information and easily deal with daily routine tasks using some trivial scripting. It is all possible because of advanced Jira Rest API.

Let’s say we have some regular tasks of some type. For example, to detect vulnerabilities on some hosts using Nessus and make a comment about founded vulnerabilities in the task. You can make a script that we will search for this kind of tasks in Jira, process them, add scan results to the comment and close the task. Of course it works the best when these tasks are also were created with in some automated way, in this case parsing will be much easier.

“Issue”, is the right name for the task in Jira; but I frequently use “issue”, “task” and “ticket” interchangeably. Sorry for this.

So, we need to take this steps:

  • Authorization
  • Search for existing Jira issues using some search request
  • View description, data and comments of the issue
  • Download files attached to the issue
  • Make some task processing
  • Add a new comment to the issue
  • Change status of the issue

Continue reading

ZeroNights16: Enterprise Vulnerability Management

17-18 November I was at the great event  Zero Nights security conference in Moscow. For the first time as a speaker. Being a part of such famous and prestigious security event was very exciting. I was talking mainly about VM solution problems and custom reporting/ticketing, Ekaterina shared some experience in using Tenable SecurityCenter for Vulnerability and Compliance management.

Presentation was recorded and some time later video will be available on YouTube. However, I suppose audio will be only in Russian not earlier than February 2017. So I think it will be a much more useful to share some points of the presentation right now. Lucky here I don’t have any time restrictions. =)

The first thing to say about Vulnerability Scanners and Vulnerability Management product is that there are plenty of them. On this picture I mentioned some of the products/vendors.

Vulnerability Scanners and Vendors

Some of them are highly specialized, like ErpScan for SAP, others are universal. Some of them are presented globally: Tenable Nessus / SecurityCenter, Rapid 7 Nexpose, Qualys, F-Secure etc., others are known mainly in Russia: Positivie Technologies Maxpatrol, Altx-Soft RedCheck, Echelon Scaner-VS. Some products are expansive, some of them not and even have versions available for free: OpenVAS, SecPod Saner Personal, Altx-Soft ComplianceCheck, Qualys SSL labsHigh-Tech Bridge SSL Server Security Test, etc.

In my opinion the main problems of VM solutions are expansiveness and low reliability of the scan results.

Continue reading

VM Remediation using external task tracking systems

In previous post I have briefly reviewed built-in remediation capabilities of vulnerability management systems. Continuing the theme, today I want to share some basic concepts how vulnerability remediation can be managed using external task tracking systems (Jira, TFS, Testrack, etc).

Jira Vulnerability Management ticket

Pros: it makes possible to implement any logic of remediation/patch management process.
Cons: you should make it by yourself; scripting skills and API knowledge required.

Tickets in buit-in remediation systems are usually assigned per host or per vulnerability. However, for large size networks making “one vulnerability on one host – one ticket” quickly become impractical. With universal task trackers we can do it in a different ways. I find it most convenient to make tickets on principle “one category of vulnerabilities, one ip range, one scanning iteration – one ticket”.
Continue reading