Resolves short term feature fix mitre/heimdall-lite#116. Standard files are big - to improve user experience, and minimize bandwidth waste, we should send as little data as is necessary (only really need the controls the user is trying to view). Request this data asynchronously via graphql, send back the relevant controls. Locally cache the ones that have been sent (not literally in the cache, just in memory).

If a filter --name is not specified that tool should process all the results and place it in the hdf json

I know I am repeating myself in various issues on this but I hope this collects a lot of these ideas.

We should also write up a 'HDF Profile and Control' Stype guide that would help lay out a lot of these 'standards' that we have established.

I am sure many of these will break out into smaller sub-issues on the vaious projects.

I am also very sure that all this stuff will have to go into the guide referenced above.

• That we update the parsing to ensure we always use sub-descriptions on text block types rather than tags:

• fix
• check
• desc

The below are used in many overlays and tailoring profiles

• /vulnerability/
• vulnerability_discussion ( in xccdf, csv and xls for example )
• /justification/
• caveat
• etc.

• That we allow for allow for three new types: desc, justification, caveat, discussion
  a. That caveat and or justification are appended to the 'Finding Details' in all the converters and Heidmall Applications
  b. We also allow for /*caveat*/ and /*justification*/ - such that myorg-/_caveat is discovered.
  c. that discussion or /*discussion*/ be appended to the bottom of the general description - such that vulnerability_discussion would be discovered.

• That we support both text based impacts and numeric based impacts in our parsing and conversations to allow for better user interface ( in xccdf, csv, xccdf etc. )

• That we update inspec_tools and heimdall_tools to use the new sub-sections

• That the sub-descriptions are grouped and created together in the control logically:

* desc [ req ]
* title [ req ]
* impact [ req ]

* desc vuln (opt)
* *vuln* (opt)

* desc caveat (opt)
* desc *caveat* (opt)

{ tags,
nist: [reg || UM-1] => if STIG || CIS
cci: [req || N/A] => if STIG || CIS
cis_cdc [ req || N/A ] => IF CIS
 }
  
* desc check [ req ]
* desc fix [ req ]

* `ref * ` (opt)

`describe blocks` [ req ]

...

• That CAT I / CAT II / CAT III can be processed and their derivities and be replaced by CVSS 3.0 standards in all our tools forward and backward - such that if someone creats a CSV or XLS they can ask to use the CVSS, CAT[I-IV] or CAT[1-4] severity style.

• That our tools do not create code that uses " where ' are the correct style

• Ensure the output of our converters formats with a standard of 2-space utf-8 conmpliant chars. Automate and other windows and ruby unzip some time have issues with the char encoding or odd things. This is an old issue but I think they are just plian using an old library or something.

• Remove the 'Rev_*' from the nist tag array as the actual mapping for the control and its nist revision is in the CCI database, and we have the CCI. This also confuses the end users as they think when the 800-53 mapping changes we have rework the profile and silly things like that. Less is more.

• Convert all our XLS mapping systems into proper ruby data structures that the tools and apps. Allow for us to be able to use the XLS as a source but convert that into our stable ruby defined structures so that in the binary builds we are alows useing pure ruby objects and data structures which can can loaded as static constancts so we only have to load them one etc.

As a note, once we have Compliance Mapper working - we can just interact and gen these data there.

• Ensure the output of our converts creates well formatted aligned starting point - I think rubocop can be fanagled to support this. See the Windows 10 profile for an example - given I had to review every control I just did this by hand on the 243 controls ... I would prefer never to do that again.

# encoding: utf-8

control 'V-63319' do
  title "Domain-joined systems must use Windows 10 Enterprise Edition 64-bit
        version."
  desc  "Features such as Credential Guard use virtualization based security to
        protect information that could be used in credential theft attacks if
        compromised. There are a number of system requirements that must be met in
        order for Credential Guard to be configured and enabled properly.
        Virtualization based security and Credential Guard are only available with
        Windows 10 Enterprise 64-bit version."
  impact 0.5
  tag severity: 'medium'
  tag gtitle: 'WN10-00-000005'
  tag gid: 'V-63319'
  tag rid: 'SV-77809r3_rule'
  tag stig_id: 'WN10-00-000005'
  tag fix_id: 'F-69237r2_fix'
  tag cci: ['CCI-000366']
  tag nist: ['CM-6 b']
  tag false_negatives: nil
  tag false_positives: nil
  tag documentable: false
  tag mitigations: nil
  tag severity_override_guidance: false
  tag potential_impacts: nil
  tag third_party_tools: nil
  tag mitigation_controls: nil
  tag responsibility: nil
  tag ia_controls: nil

  desc "check", "Verify domain-joined systems are using Windows 10 Enterprise
        Edition 64-bit version.

        For standalone systems, this is NA.

        Open \"Settings\".

        Select \"System\", then \"About\".

        If \"Edition\" is not \"Windows 10 Enterprise\", this is a finding.

        If \"System type\" is not \"64-bit operating system…\", this is a finding."

  desc "fix", 'Use Windows 10 Enterprise 64-bit version for domain-joined systems.'

  describe os.arch do
    it { should eq 'x86_64' }
  end

  describe os.name do
    it { should eq 'windows_10_enterprise' }
  end
end

• Given the above, can we create a .rubocop standard file that would help enfore a lot of this

See inspec/inspec#4235 and its dependent PR's one of which is inspec/inspec#3706

https://en.gravatar.com/site/implement/profiles/jsapi/

Really no reason not to...

See gh-pages branch and the signle page build which is likely breaking our docker container build

Please enable HTML rendering in the Test Details tag

This especially meaningful for heimdall tools json view

H-Lite view

Current Heimdall view

After we get our first cut done, I would like to see if we could add support in the treemap to also support the CIS control mappings as well.

Our cis profiles will need some tag standardization but the core of the data set is here:
https://learn.cisecurity.org/cis-controls-download
CIS Controls Version 7.0.1.a cc.xlsx
CIS Controls Version 7.1 Implementation Groups 1.2.xlsx
CIS-Controls-and-Sub-Controls-Mapping-to-NIST-CSF.xlsx

CIS-Controls-V7.1-Change-Log.xlsx
CIS-Controls-Version-7-1.pdf

• add the s3 docs to the readme
  ( link to aws does and perhaps an example )
• copy the needed setup info from the hdf-to-splunk readme to the HL readme (https://github.com/mitre/hdf-json-to-splunk#reading-this-data-back-out-in-heimdall-lite)
• add an info chip and model or link to the S3 docs or copy them in as text which ever works best
• add a 'notice' color or something that indicates to the user that this action is needed prior to accessing data

Add the ability for inspecjs to support the inspec_profile schema

Describe the bug
Heimdall 1 supported rendering HTML (and respected \n for newlines), heimdall 2 provides the data as a large dump with no separation.

To Reproduce
Steps to reproduce the behavior:

1. Import an
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
https://github.com/mitre/heimdall_tools/blob/master/sample_jsons/zap_mapper/webgoat.json loaded into heimdall 1 and 2:


https://raw.githubusercontent.com/mitre/heimdall_tools/master/sample_jsons/sonarqube_mapper/sonarqube_java_sample.json loaded into heimdall 1 and 2:

Additional context
Most likely need to sanitize for bad data since this frontend will now be used for both a standalone and a server application: https://www.npmjs.com/package/vue-sanitize

This issue(s) more relevant to heimdall, specifically, but is more likely to hold my attention if placed here. Some of these goals may already be accomplished, but they are repeated here nonetheless.

Essentially, as we refactor Heimdall DB to support Heimdall lite, we should also make sure that:

• Heimdall DB stands on its own and needs no communication with the server to have total data independence/integrity
  • In particular, it is my belief that we should firmly separate the concept of users viewing evaluations from the evaluations themselves
  • This ensures that we will have a "pure data" / HDF data format central to our architecture, and that other developers can easily utilize the Heimdall DB if they wish to make their own frontend (or have no frontend at all).
  • This will hopefully aid in wider adoption of Heimdall platform tools, as people can take exactly what they want/need (storage, file format conversion, UI, etc.) without needing to use the entire monolithic platform.
  • It will also make transitioning from current Heimdall Server frontend to Heimdall lite simpler.
• Heimdall DB ingest layer should be separated from Heimdall frontend
  • Similar line of reasoning as above: Modularity makes transitions between different frontends simpler.
  • Furthermore, if an organization discovers a need to massively scale up the amount of data they are intaking, it would behoove us to make sure our intake procedures can scale as well.
    • This also would improve resiliency, as we won't drop data just because the frontend is down.
• Heimdall DB should enforce data correctness (to the best of its ability)
  • Third normal form is ideal, and I see no reason for us not to have it.
  • Avoid nulls wherever possible - they are frustrating to deal with, and in almost every case I would argue that the person submitting the data knows a better method of establishing default values than some poor frontend developer (won't someone please think of the interns! and me).

We need to:

• Give errors in a more useful format. Direct users to which fields could probably be most useful/ likely to be causing the error.
• Remind the user to turn on CORS if network fails, with link to appropriate splunk documentation pages.
• Use pictures!

Maybe more things later? IDK

E.g. Search by SHA, whether it failed, compliance rate, etc. All these will need to be placed in the meta tag, and the search should specifically run on the meta tag, if possible.

Simplifies use case, maybe.

Current blocker: I have no idea how.

Full Data: The current function of the CAAT component.

Condensed/Interactive:
Use Case:
A user wants to fold each NIST Sub-Family into single row rather than multiple rows for every result. If they select the condensed mode - we will have a 'wizard model' come out and ask what 'standard text' we want for each column for that Sub-Family Finding - walking them across the spreadsheet.

As the user is walking though each sub-family step - It would be good if we can have another model that has a datatable of the 'detailed results' of those findings for the sub-family that they could open and close for review if needed.

UX consideration: we can we can suggest a 'default' answer -
a) like Severity ( if 8 / 10 are high or they are all the same) or
b) if they have already provided an answer - such as 'System Name' - that is unlikely to change. ( perhaps the last answer is good enough for most cases ).
c) Could use vuetify modal

Once they walk through, they can save it as a csv/xlsx.

Derived from mitre/heimdall-vue#14

Profile parser Should coerce NIST tags to a list, otherwise calling forEach on nist tags is unpredictable, and may not work

https://github.com/inspec/inspec/tree/cw/add-html2-reporter

This was an idea that we already pushed to the inspec folks about updating the html reporter to just use a SPA version of HL - a bit modified - to save the results data into the Single page build of HL to make a much better version of the HTML reporter.

This is a good start but as you can see - it is not so pretty

@lukemalinowski did a lot of work with the Webpack build of HL so he may be a good resource

Implement heimdall2 (w/ frontend) build preview on Heroku

As an Information System Owner, I need to be able to define and track manual tests so I know when control compliance needs to be reevaluated.

Now that it has proper expansion support,
https://vuetifyjs.com/en/components/data-tables#expandable-rows

and proper custom rows,
https://vuetifyjs.com/en/components/data-tables#customizing-default-rows

many of our initial reasons for simply using a list view are now moot.

This would solve the alignment issues and potentially/almost definitely. increase performance for paginated views.

However, the main reason to NOT make this change is that the initial implementation by the Vuetify devs was incredibly inefficient when doing the "all" view for extremely large #'s of rows. We must weigh the cost of development against the chance that this inefficiencies are still crippling. Additionally, we would lose our nifty stacking - however, said stacking is kind of a PITA to maintain.

Describe the bug

1. The favicon should have a transparent background instead of being black.

2. Should also probably include more sizes in it to support a wider variety of usages.

3. Also, where did we derive the art from? Other projects called Heimdall have similar logos so not sure if ours is outdated or something, ex. https://heimdall.site/.

See:

https://stackoverflow.com/questions/1344122/favicon-png-vs-favicon-ico-why-should-i-use-png-instead-of-ico

and

https://realfavicongenerator.net/blog/favicon-why-youre-doing-it-wrong/

To Reproduce
Steps to reproduce the behavior:

1. Look at how kinda grungy the favicon looks.

Expected behavior
Favicon should look clean.

Screenshots

Desktop (please complete the following information):

• OS: macOS Catalina
• Browser: Firefox
• Version: 75

For example, an IfThisThenThat - style service could send digests of Inspec report activity, and forward them to arbitrary notification systems (e.g. phone notifications, emails, etc) with little additional dev work on our end.

The community has requested that we have a second treemap view that groups by a set of capabilities which are aligned to NIST SP 800-53 controls.

For a beta we could just have a simple mapping of:

CAP 1: AC-2
CAP 1: AC-2(4)
CAP 2: CM-5
...
CAP16: ...

and then we can replace the 16 capabilities with the real labels.

We will also have to add a column and chips into the datatable to display and sort by this additional metadata.

At the moment the Results vue layout shows profile errors for InSpec Profile JSONs.

Given that the sidebar seems to know the difference between Results and Profile json's we should just have a second view for Profiles with a logical layout similar to the HL1.0.

• Use the added NPM_TOKEN secret I put in the repo

MVP

• How do upload a file
• basic walkthrough of the areas
• filtering
• showing some conversions
  • CATT
  • Control Coverage
• Local file, S3 or Splunk

As a Security Control Assessor, I need to be able to review evidence of control compliance while adhering to the principle of least privilege.

Read-only user access control for circles seems like the most common use case here.

When exporting a CAAT file, the cells containing data for the following columns are not formatted, primarily carriage returns and line feeds missing:

• weakness description
• test objective
• test result
• recommended corrective action(s)

A Summary version of the CAAT, listing only one row for each NIST SP 800-53 security control.
A template/mockup is attached:
Summary_CAAT_Template_02062020a.xlsx
And add menu item as shown:

This will help ease our support burden to the end-users as where to find the needed data for backend sources should be easy.

S3 - how do I find my ARN, ... other info asked for
Splunk - how do I find the 'requested items' in the list

a simple "help" or (i) info popup could help keep them from sending silly email questions.

• https://docs.npmjs.com/files/package.json
• https://hackernoon.com/how-to-publish-your-package-on-npm-7fc1f5aae600
• https://areknawo.com/whats-what-package-json-cheatsheet/

We need to:

• Give errors in a more useful format. Direct users to which fields could probably be most useful.

• Remind the user to turn on CORS if network fails, with link to https://docs.aws.amazon.com/AmazonS3/latest/user-guide/add-cors-configuration.html (popup modal after 2-3 fails. User can dismiss temporarily).

• Use pictures!

Maybe more things later? IDK

Message, status, etc. should be cached because being honest, CPU costs more than memory in JS world (gross!). Also, HDF objects are now less common since we generate them at intake time, so it's all good.

Technically this is an inspecJS thing but that doesn't matter - who cares - things aren't real.

As a Information System Owner, I need a combined view that aggregates the results of several scans so I can understand the overall security posture of a system or system component.