Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect time format within Security Center integrations. Possibly timzone/timing issue? #292

Closed
zerokid opened this issue Aug 13, 2024 · 8 comments

Comments

@zerokid
Copy link

zerokid commented Aug 13, 2024

After make the second snyc call this error will return

Screenshot 2024-08-13 at 12 57 38 PM
@SteveMcGrath
Copy link
Collaborator

alrighty, should be corrected now.

@zerokid
Copy link
Author

zerokid commented Aug 15, 2024

its still not working @SteveMcGrath . i think because of the timezone different

@SteveMcGrath
Copy link
Collaborator

Thats really odd, as I can't seem to replicate that. From the debug logs on 2.0.9 it appears that everything is working as expected. Timezones shouldn't matter for unix timestamps, as they count seconds since 1/1/1970 UTC. The only thing i could think of is maybe the time is wrong on the SC host itself?

Note that in the filter I'm seeing the STARTTIME-ENDTIME format expected:

{"filterName": "lastSeen", "operator": "=", "value": "1723552747-1723742640"}

Log even (formatted for readability) from a TSC sync with --verbose:

DEBUG    DEBUG:tenable.sc.TenableSC:Request: {
    "method": "POST",
    "url": "https://sc.tenalab.online/rest/analysis",
    "params": {},
    "body": {
        "type": "vuln",
        "sourceType": "cumulative",
        "query": {
            "tool": "vulndetails",
            "type": "vuln",
            "filters": [
                {"filterName": "ip", "operator": "=", "value": "10.238.64.0-10.238.64.255"},
                {"filterName": "severity", "operator": "=", "value": "2,3,4"},
                {"filterName": "lastSeen", "operator": "=", "value": "1723552747-1723742640"}
            ],
            "startOffset": 0,
            "endOffset": 1000
        }
    }
}

@SteveMcGrath SteveMcGrath reopened this Aug 15, 2024
@zerokid
Copy link
Author

zerokid commented Aug 15, 2024

This is what i notice in my config it will add the last run timestamp
Screenshot 2024-08-16 at 7 02 26 AM

as i check it actually get the wrong unix timestamp. im on gmt+8 and it suppose to reflect +8 7AM
Screenshot 2024-08-16 at 7 06 01 AM

this is my verbose output
Screenshot 2024-08-16 at 7 04 07 AM

@SteveMcGrath
Copy link
Collaborator

I'm quite confused. Looking at this:

The timestamp of the last run is set here: https://github.com/tenable/integration-jira-cloud/blob/main/tenb2jira/tenable/tenable.py#L29
The timestamp of the current run is set here: https://github.com/tenable/integration-jira-cloud/blob/main/tenb2jira/tenable/tenable.py#L89
And the timestamp filter is built here: https://github.com/tenable/integration-jira-cloud/blob/main/tenb2jira/tenable/tenable.py#L102

All of these times are on the same host, so even if timezones were an issue, they should be uniformly an issue. How you are getting 1723791640 (16-8-2024 07:00:40) to 1723762981 (8-15-2024 23:03:01) in GMT on both is odd. I'll look into this further Monday morning.

@SteveMcGrath SteveMcGrath changed the title Start time must be later (i.e. less than) than end time. Filter \'lastSeen\' must be in the following format: <start time>-<end time>.\\n","warnings":[],"timestamp":1723518078}\n Incorrect time format within Security Center integrations. Possibly timzone/timing issue? Aug 16, 2024
@SteveMcGrath
Copy link
Collaborator

so i did find something that may have caused this. spent a bit of time cleaning up all the timestamps to always use UTC regardless.

@SteveMcGrath
Copy link
Collaborator

Give that commit a try:

pip install https://github.com/tenable/integration-jira-cloud/archive/refs/heads/fix/timestamps.zip

SteveMcGrath added a commit that referenced this issue Aug 21, 2024
* Pushed all times to UTC.  added debug flag. #292

* Additional corrections to timestamps.

- Corrected issue with comparing naive timestamps with aware timestamps.
- Added mapping DB cleanup to sync

* Reverting casting float to string #294

* Updated testing suite
@SteveMcGrath
Copy link
Collaborator

2.0.10 entered release with the changes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants