Recently, I helped the system team recruit [AI Security Researcher] (social recruitment), and most of the resumes I received were AI algorithm engineers, and I asked how to migrate AI capabilities to the field of network security, and most of the answers I got were that AI is very popular, AI is widely used, and I lack understanding of the field of network security, and I don't know how to empower network security. I think that the key to the difficulty of cross-cutting fields is the ability transfer, so I have to ask the interviewee: What is your most successful ability transfer?
AILX10
Excellent answerer in cybersecurity
Master's in Cybersecurity
Go to consult
To put it bluntly, capability transfer is to imitate first and then innovate, I took a look at the official English documentation of neo4j, and then quickly imitated the prototype of the knowledge graph. Another example is to build a 3-part diagram, but you need to know how to build a 2-part diagram first, so the work also needs to be gradual, decompose a big goal, and then keep simulating, quickly produce a demo, and can't systematically engage in a large and complete design, which will often end up because you can't see the effect.
To build a two-part diagram, we can do the following:
CREATE CONSTRAINT UniqueIPNode ON (p:IPNode) ASSERT p.ipID IS UNIQUE;
CREATE CONSTRAINT UniqueDomainNode ON (o:DomainNode) ASSERT o.domainID IS UNIQUE;
CREATE CONSTRAINT UniqueResponseIPNode ON (q:ResponseIP) ASSERT q.responseID IS UNIQUE;
LOAD CSV WITH HEADERS FROM 'file:///IPNode.csv' AS row
WITH toInteger(row.ipID) AS ipID, row.IP AS IP, row.City AS City
MERGE (p:IPNode {ipID: ipID})
SET p.ip = IP, p.city=City
RETURN count(p);
LOAD CSV WITH HEADERS FROM 'file:///RequestDomain.csv' AS row
WITH toInteger(row.domainID) AS domainID, row.Domain AS Domain, toInteger(row.DomainLen) AS DomainLen, toInteger(row.SubDomainLen) AS SubDomainLen
MERGE (p:DomainNode {domainID: domainID})
SET p.domain = Domain, p.domainlen=DomainLen, p.subdomainlen=SubDomainLen
RETURN count(p);
:auto USING PERIODIC COMMIT 500
LOAD CSV WITH HEADERS FROM 'file:///Request.csv' AS row
WITH toInteger(row.ipID) AS ipID, toInteger(row.domainID) AS domainID, row.ResponseIP AS ResponseIP, toInteger(row.TTL) AS TTL
MATCH (p:IPNode {ipID: ipID})
MATCH (o:DomainNode {domainID: domainID})
MERGE (p)-[rel:Request {response: ResponseIP,ttl:TTL}]->(o)
RETURN count(rel);
:auto USING PERIODIC COMMIT 500
LOAD CSV WITH HEADERS FROM 'file:///MainDomain.csv' AS row
WITH toInteger(row.fatherID) AS fatherID, toInteger(row.childID) AS childID
MATCH (f:DomainNode {domainID: fatherID})
MATCH (c:DomainNode {domainID: childID})
MERGE (c)-[rel:Main ]->(f)
RETURN count(rel); So to build the 3-part diagram, we only need to add a little bit of scripting, and I think this is the rapid transfer of knowledge:
LOAD CSV WITH HEADERS FROM 'file:///ResponseIP.csv' AS row
WITH toInteger(row.responseID) AS responseID, row.ResponseIP AS ResponseIP, toInteger(row.TTL) AS TTL
MERGE (p:ResponseIP {responseID: responseID})
SET p.responseip = ResponseIP, p.ttl=TTL
RETURN count(p);
:auto USING PERIODIC COMMIT 500
LOAD CSV WITH HEADERS FROM 'file:///response.csv' AS row
WITH toInteger(row.domainID) AS domainID, toInteger(row.responseID) AS responseID
MATCH (p:ResponseIP {responseID: responseID})
MATCH (o:DomainNode {domainID: domainID})
MERGE (o)-[rel:Response ]->(p)
RETURN count(rel); Finally, we can take a look at the picture drawn, is it very simple~